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SECTION  1  -  INTRODUCTION 

1.1  OBJECTIVE  OF  PAPER 

This  paper  contains  the  software  design  specifications  for 
an  aid  for  systematically  estimating  manpower  requirements  for 
Army  weapon  systems  following  the  initial  detailed  interface 
design  but  prior  to  the  decision  to  fund  the  hardware/software 
prototype.  The  Manpower  Determination  Aid  (MDA)  is  one  of  six 
products  being  developed  in  the  Army  Research  Institute's  (ARI) 
Manpower,  Personnel,  and  Training  aids  for  the  MANPRINT 
integration  (MPT)^  project. 

The  design  specification  describes  requirements  for  this 
aid,  and  presents  a  detailed  description  of  the  aid's  steps  and 
the  techniques  for  developing  them.  It  also  delineates  the 
software  design. 

This  design  specification  is  the  second  step  in  a  three- 
step  development  process.  The  first  step  was  to  develop  a 
concept  paper  describing  the  functionality  of  the  MDA  in  concept. 
In  this  second  step,  detailed  design  specifications  have  been 
developed.  In  the  third  step,  software,  documentation,  and 
training  for  the  aid  will  be  produced  and  demonstrated. 

NOTE:  IT  IS  NOT  THE  INTENTION  OF  THIS  SPECIFICATION  TO  PRESENT  A 

DETAILED  DISCUSSION  OF  THE  CONCEPTS  BEHIND  THE  MDA.  FOR  A 
DISCUSSION  OF  THE  MDA  CONCEPTS,  REFER  TO  THE  CONCEPT  PAPER. 
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1.2  OVERVIEW  OF  (MPT) 2  PROCUCTS 


Figure  1  displays  the  six  (MPT)^  products  and  their 
expected  role  in  the  Army's  new  streamlined  Materiel  Acquisition 
Process  (MAP) .  The  first  four  products,  the  System  Performance 
Requirements  Estimation  Aid,  the  Manpower  Constraints  Estimation 
Aid,  the  Personnel  Constraints  Estimation  Aid,  and  the  Training 
Constraints  Estimation  Aid,  are  designed  to  estimate  MPT-related 
requirements  and  constraints  during  the  Requirements/Technology 
Base  Activities  Phase  of  the  MAP.  These  requirements  and  con¬ 
straints  will  guide  subsequent  contractor  design  activities. 

The  System  Performance  Requirements  Estimation  Aid  (SPREA) 
will  help  Army  combat  developers  identify  comprehensive  and 
unambiguous  system  performance  requirements  needed  to  accomplish 
various  missions. 

The  next  three  (MPT)^  products  are  designed  to  determine 
MPT  constraints.  The  Manpower  Constraints  Estimation  Aid  (MCEA) 
will  identify  the  maximum  crew  size  for  operators  and  maintainers 
and  the  maximum  Direct  Productive  Annual  Maintenance  Manhours 
(DPAMM)  for  maintainers.  These  constraints  will  be  based  on 
assessments  of  the  manpower  likely  to  be  available  to  man  the  new 
system. 


The  Personnel  Constraints  Estimation  Aid  (PCEA)  will 
estimate  the  significant  personnel  characteristics  that  describe 
and  limit  the  capabilities  of  the  probable  soldier  population 
from  which  the  new  system's  operators  and  maintainers  will  come. 
The  PCEA  will  identify  the  minimally  acceptable  boundaries  for 
these  characteristics. 


The  Training  Constraints  Estimation  Aid  (TCEA)  will 
identify  what  the  training  program  for  the  new  system  is  likely 
to  look  like  given  current  training  practices  in  the  field.  It 
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Figure  1.  Expected  Role  of  Six  (MPT)  2  Products. 


will  also  determine  the  maximum  training  time  available  to  train 
the  personnel  given  available  training  resources. 

The  last  two  products  help  evaluate  initial  contractor 
designs.  The  Manpower  Determination  Aid  (MDA)  and  the  Personnel 
Requirements  Estimation  Aid  (PREA)  are  designed  for  use  during 
the  Proof  of  Principle  Phase.  They  will  be  used  after  initial 
contractor  designs  have  been  submitted,  but  before  one  design  is 
chosen  to  develop  into  a  prototype.  These  products  evaluate 
initial  contractor  designs  and  develop  MPT  alternatives  that 
minimize  personnel  characteristic  deficits  (i.e.,  discrepancies 
between  the  type  and  number  of  people  required  and  the  number  of 
these  people  likely  to  be  available  when  the  system  is  fielded) . 

The  Manpower  Determination  Aid  (MDA)  determines  the  quanti¬ 
tative  manpower  requirements  needed  to  support  a  contractor 
design  by  assessing  the  workload  associated  with  the  tasks  that 
the  contractor  design  specifies. 

The  Personnel  Requirements  Estimation  Aid  (PREA)  determines 
the  type  and  level  of  personnel  characteristics  needed  to  support 
the  effective  performance  of  each  task  associated  with  a 
contractor  design. 

Personnel  characteristic  requirements  for  individual  tasks 
are  then  aggregated  to  produce  estimated  personnel  characteristic 
requirements  at  the  job  or  duty  position  level.  These  job  re¬ 
quirements  are  multiplied  by  the  quantitative  manpower  require¬ 
ments  to  determine  the  total  number  of  individuals  with  various 
levels  of  personnel  characteristics  that  are  required  to  support 
that  design.  The  personnel  characteristic  distribution  this 
analysis  produces  can  then  be  compared  with  personnel  character¬ 
istic  constraints  to  identify  deficits. 
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The  results  of  these  two  evaluative  aids  will  be  used  to 
select  a  specific  design  alternative  for  further  development.  As 
such,  the  results  can  be  incorporated  into  higher  level  analyses 
such  as  the  Cost  and  Operational  Effectiveness  Analysis  (COEA) . 
The  PREA  will  provide  MANPRINT  analysts  with  the  information 
needed  to  effectively  make  the  '‘go/no  go”  decision  at  the  end  of 
the  Proof-of-Principle  Phase. 


1.3  ORGANIZATION  OF  THE  SPECIFICATION 

The  remainder  of  this  specification  paper  is  organized  into 
four  sections.  The  next  section  on  product  requirements  includes 
the  product's  objectives,  significant  output,  users,  role  in  the 
acquisition  process,  assumptions,  and  the  high-level  functional 
requirements/constraints  associated  with  it. 

Section  3  describe  in  detail  the  software  specifications 
for  the  two  modules  that  make  up  the  MDA;  the  Workload  Assessment 
Aid  (WAA)  and  the  Maintenance  Manpower  Analysis  Aid  (MMAA) . 
Included  in  this  description  is  a  step-by-step  presentation  of 
the  user  interface  of  the  MDA. 

The  MDA  will  contain  two  types  of  files  —  libraries  which 
describe  "hardwired”  input  data  and  working  files  that  are  used 
to  store  results  related  of  a  particular  application.  The 
working  files  will  be  used  as  input  to  the  simulation  models  that 
will  produce  the  output  files  for  Product  5.  Descriptions  and 
data  structures  for  these  two  types  of  files  can  be  found  in 
sections  4  and  5  of  this  specification.  The  description  of  the 
libraries  also  includes  some  of  the  actual  values  for  the 
"hardwired”  input  data. 

Section  6  describes,  in  detail,  the  simulation  models  that 
will  be  used  in  the  MDA  to  determine  manpower  requirements. 
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Section  7  provides  a  discussion  of  the  technology  transfer 
issues  that  relate  to  Product  5.  Included  in  this  section  are 
specifications  for  user  and  programmer  documentation  that  will  be 
produced  for  the  Product  5  software. 
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SECTION  2  -  PRODUCT  REQUIREMENTS 


2 . 1  OBJECTIVES 

The  purpose  of  the  Manpower  Requirements  Determination  Aid 
(MDA)  is  to  determine  the  quantitative  manpower  requirements  for 
a  specific  contractor's  design.  The  MDA  will  be  used  during  the 
Proof-of-Principle  Phase,  after  the  contractor  submits  the 
initial  designs,  but  before  one  design  is  chosen  to  develop  into 
a  prototype.  The  Manpower  Determination  Aid's  output  will  be 
used  with  the  output  from  Product  6.  The  combined  output  will 
help  develop  manpower,  personnel,  and  training  (MPT)  alternatives 
that  minimize  personnel  characteristics  deficits.  These  deficits 
are  discrepancies  between  the  type  and  number  of  people  required 
and  the  number  of  such  people  likely  to  be  available  when  the 
system  is  fielded. 


2.2  MAJOR  OUTPUT 

The  MDA  will  determine  manpower  requirements  for  each 
contractor  design.  These  requirements  will  include:  1)  the  jobs 
associated  with  each  design,  2)  the  tasks  associated  with  each 
job,  and  3)  the  number  of  operators  or  maintainers  in  each  job. 
In  addition  to  defining  manpower  requirements  by  job  or  duty 
position,  the  MDA  will  be  capable  of  assigning  each  job  to  an 
MOS,  and  calculating  total  manpower  requirements  by  military 
occupational  specialty  (MOS),  skill  level,  major  component  item 
(for  maintainers  only) ,  and  maintenance  level  (for  maintainers 
only)  . 


In  addition  to  producing  manpower  requirements  estimates, 
the  MDA  will  have  the  capability  to  estimate  system  availability, 
reliability,  and  operational  effectiveness.  We  will  compare 
these  estimates  with  the  requirements  that  the  System  Performance 
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Requirements  Estimation  Aid  (Product  1)  identified  during  the 
Requirements  Technology  Base  Activities  Phase  of  the  Materiel 
Acquisition  Process  (MAP) .  This  comparison  can  identify  short¬ 
falls  (discrepancies  between  requirements  and  estimates  based  on 
contractor  design) . 


2.3  ROLE  OF  PRODUCT  5  OUTPUT  IN  ACQUISITION  PROCESS 

During  the  acquisition  process,  manpower  requirements  for 
an  emerging  system  are  described  primarily  in  two  documents. 

These  documents  are  the  basis-of-issue  plan  (BOIP)  and  the 
qualitative  and  quantitative  personnel  requirements  information 
(QQPRI)  documents.  This  section  explains  how  these  documents 
present  quantitative  manpower  requirements,  where  the  information 
comes  from,  and  who  is  responsible  for  this  information. 

The  MDA  will  be  designed  to  provide  input  to  these  two 
documents . 

BOIP 


The  BOIP: 

"States  the  number  of  new  or  improved  items  of 
equipment  and  personnel  to  be  included  in  Tables  of 
Organization  and  Equipment  (TOE)  Level  1  (100  percent 
wartime  requirements) ,  Tables  of  Distribution  and 
Allowances  (TDA) ,  Joint  Tables  of  Allowances  (JTA) , 
Additive  Operational  Projects  (AOP) ,  and  TDA 
Augmentation  to  Modified  Tables  of  Organization  and 
Equipment  (MTOE)  when  directed  by  HQDA."  (Revised  AR 
71-2,  Section  1-5) 
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The  BOIP  must  justify  the  Manpower  requirements  it  includes 
by  clearly  stating: 

•'The  rationale  considered  in  determining  the  type  and 
number  of  items  and  personnel  needed  to  support  the 
principal  item  (QQPRI,  operator  and  maintainer 
decision) .  Personnel  increases  exceeding  requirements 
document  estimates  will  be  justified  or  trade-off 
assessment  completed."  (Section  5-9) 

The  Deputy  Chief  of  Staff  for  Operations  and  Plans  (DCSOPS) 
is  the  AxTtiy  staff  proponent  for  the  BOIP  system. 

QQPRI 

The  revised  AR  71-2  describes: 

"The  QQPRI... [as]  a  compilation  of  organizational, 
doctrinal,  training,  duty  position,  and  personnel 
information.  It  is  prepared  for  a  new  or  improved  item 
of  equipment  by  the  materiel  developer  in  coordination 
with  the  combat  and  training  developer. . .The  QQPRI  is 
used  as  follows: 

(1)  To  determine  the  need  to  establish  or  revise 
a  Military  Occupational  Specialty  (MOS) , 

Specialty  Skill  Identifier  (SSI) ,  and 
civilian  OPMCS. 

(2)  To  prepare  plans  to  provide  the  personnel  and 
training  needed  to  operate,  maintain,  and 
transport  the  new  or  improved  item  of 
equipment. 

(3)  As  a  source  document  for  direct  productive 
annual  maintenance  manhours  (DPAMMH)." 
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Figure  2  presents  the  QQPRI  format.  One  of  the  QQPRI's  key 
components  is  the  DPAMMH: 

"[The]  DPAMMH  will  be  based  on  the  empirical  data  or, 
as  a  minimum,  estimated  hours  will  be  submitted  and  so 
identified  for  all  developmental  items  of  equipment  or 
system.  Hours  will  be  expressed  by  MOS,  SSI,  and  OPMCS 
for  each  category  of  maintenance  (UL,  IDS,  IGS,  AVIM, 

AVUM) .  When  LSA  data  or  engineering  estimates  are 
sources  for  DPAMMH,  the  annual  usage  rate  used  in  the 
computation  should  be  provided.  This  annual  usage  rate 
should  be  a  derivative  of  equipment  mission  profile 
found  in  the  appropriate  materiel  need  document.” 

(Section  4.8) 

According  to  AR  71-2,  the  QQPRI  also  presents: 

•'The  number  of  direct  operators  needed  to  make  up  a 
crew  or  operate  the  system  as  a  single  shift  and  a 
listing  of  duty  positions,  by  descriptive  title, 
required  for  operation  and  maintenance  of  the  equip¬ 
ment.  [It  also  contains]  a  suggested  placement  of  duty 
positions  within  a  current,  revised,  or  new  commis¬ 
sioned  officer  SSI,  or  warrant  officer  or  enlisted  MOS, 
special  qualification  identifier  (SQI) ,  ASI,  or 
civilian  OPMCS. 


A  listing  of  the  individual  system  unique  duties  and 
tasks  to  be  performed  in  each  of  the  above  identified 
positions  requiring  new,  revised,  or  current  MOS,  SSI 
and  OPMCS.  Other  special  characteristics  (e.g.,  a 
certain  height  to  operate  equipment,  a  security 
clearance  required  to  operate  or  maintain  the  equipment 
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TITLE:  The  title  of  the  QQPRI  will  identify  the  type  of  QQPRI,  the  title  of  the  principal  item,  the  LIN,  PIP 
number,  and  the  new  equipment  training  plan  (NETP  number).  This  same  title  will  be  used  on  all 
correspondence  forwarding  the  QQPRI  through  channels.  Note:  Once  TRADOC  assigns  the  BOIP 
number,  the  numbers)  will  be  included  in  all  subsequent  correspondence. 

1 .  REQUIREMENT  INFORMATION: 

a.  Requirement  or  Procurement  Directive: 

b.  Type  Classification  (TO)  date: 

c.  First  Unit  Equipped  date  (FUED): 

d.  Army  Modernization  Information  Memorandum  (AMIM)  Number:  (Notel) 

2.  DESCRIPTION  AND  DIRECT  PRODUCTIVE  ANNUAL  MAINTENANCE 
MANHOURS  (DPAMMH):  (Notes  2,  3,  4,  and  5) 

a.  Principal  Item: 

b.  Component  Major  Item: 

c.  Total  DPAMMH  by  MOS,  SSI,  or  OPMCS  for  subparagraphs  a  and  b  above: 

d.  Associated  Support  Items  of  Equipment  (ASiOE): 

3.  NUMBER  DIRECT  OPERATORS  REQUIRED  TO  CREW  OR  OPERATE 
EQUIPMENT: 

4.  DUTY  POSITIONS  BY  DESCRIPTIVE  TITLE: 

5.  INDIVIDUAL  UNIQUE  DUTIES,  TASKS,  AND  CHARACTERISTICS:  (Notes  6  and  7) 

6.  NETP  NUMBER  AND  NET  TRAINING  BASE  REQUIREMENTS:  (Notes  1  and  8) 

(Enclosures  -  Draft  Job  Specifications) 

Note  1.  Use  ”NA"  for  paragraphs  Id  and  6  when  not  applicable. 

Note  2.  The  format  subparagraphs  a  through  d  above  will  appear  on  ail  QQPF^I.  This  format  is  very 
flexible  to  use  on  the  four  subparagraphs  (a-d)  or  can  be  expanded  by  using  "high  school  outline"  to 
accommodate  major  systems,  or  multiple  LIN  under  each  subparagraph  (a,  b,  and  d). 

Note  3.  Materiel  developers  will  identify  LIN,  nomenclature,  description,  levels  of  maintenance  (UL, 
IDS,  IGS,  AVIM,  AVUM),  MOS,  SSI,  and  civilian  OPMCS.  Materiel  developers  will  always  provide 
DPAMMH  for  the  principal  LIN  and  the  component  major  items  whether  they' are  type  classified  or  not. 
Additionally,  the  materiel  developers  will  provide  DPAMMH  for  all  ASIOE  that  have  developmental 
items.  For  type  classified  ASIOE,  the  materiel  developer  will  list  the  LIN  and  nomenclature  only. 
DPAMMH  will  be  based  on  the  empirical  data,  or  as  a  minimum,  estimates  will  be  submitted  and  so 
identified.  DPAMMH  should  represent  the  maintenance  burden  generated  by  one  item  of  equipment 
during  one  year.  When  LSA  data  or  engineering  estimates  are  sources  for  DPAMMH.  the  annual 
usage  rate  used  in  the  computation  should  be  provided.  This  annual  usage  rate  should  be  derivation 
of  equipment  mission  profile  found  in  the  appropriate  materiel  need  document.  Usage  of  "Note"  to 
explain  information  or  rationale  is  encouraged. 

Note  4.  Formatting  for  each  LIN  under  the  subparagraph  a  and  b  including  the  type  of  equipment  is 
below.  MCI  will  be  subdivided  by  developmental  item(s)  and  type  classified  item(s):  show  NSN  or  PN 
forallCMI. 


Figure  2.  qqpri  Format. 
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LIN,  Generic  Nomenclature,  Description  (for  TMDE  start  the  description  with  the  term  TMDE*  and 
include  Central  TMDE  Activity  (CTA)  approval  number) 

MOS/SSI/OPMCS  LL  JDS.  IS 

Note  5.  Subparagraph  c  is  to  be  calculated  on  the  basis  of  one  principal  item  and  any  CM  I  in  required 
quantities.  Formatting  will  be: 

MQS/SSI/OFMCS  DP/MyH 

Note  6.  Paragraph  5  above: 

a.  Do  not  include  skills.  The  SGA  determines  the  skill  level. 

b.  Include  MOSs  that  support  the  maintenance  levels  of  all  ASIDE. 

c.  For  aviation  equipment,  include  any  ground  maintenance  that  is  not  authorized  in 
AVUM/AVIM,  but  are  at  the  UL,  IDS,  and  IGS  level  of  maintenance. 

Note  7.  Paragraph  5  above: 

a.  If  the  duties  and  tasks  listed  in  AR  61 1  -1 01 ,  AR  61 1  -1 1 2,  or  AR  61 1  -201  are  adequate ,  use 
the  following  for  each  MOS  or  SSI: 

FOR  COMMISSIONED  OFFICERS; 

SSI. . .  (indicate  any  SOI  here)  performs  duties  and  tasks  as  listed  in  AR  6‘1 1-101 . 

FOR  WARRANT  OFFICERS  OR  ENLISTED: 

MOS. .  .  (indicate  any  ASI  or  SQl  here)  performs  duties  and  tasks  as  listed  in  (AR  611-112,  AR 
611-201). 

b.  If  the  duties  and  tasks  listed  in  AR  611-101,  AR  611-112,  AR  611-201  do  not  include  the 
system  unique  duties,  tasks,  or  characteristics,  use  the  following  for  each  MOS  and  SSI: 

FOR  COMMISSIONED  OFFICERS: 

SSI. . .  (indicate  any  SQl  here) ....  (indicate  system  unique  duties,  tasks,  characteristics).  Other 
duties  and  tasks  are  listed  in  AR  611-101 . 

FOR  WARRANT  OFFICERS  OR  ENLISTED: 

MOS. . .  (indicate  any  ASI  or  SQl  here). . . .  (indicate  system  unique  duties,  tasks,  characteristics). 
Other  duties  and  tasks  are  listed  in  (AR  611-112  or  AR  611-201). 

c.  If  the  duties  and  tasks  in  AR  611-101,  AR  611-112  or  AR  611-201  need  to  be  revised,  use  the 
following  for  each  MOS  and  SSI: 


Figure  2.  QQPRI  Format  (Continued). 
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FOR  COMMISSIONED  OFFICERS: 


Revised  SSI. . .  (indicate  any  current  or  new  SOI  here).  Draft  proposed  job  specifications  are 
attached  at  enclosure. . .  .  Other  duties  and  tasks  are  listed  in  AR  611-101 . 

FOR  WARRANT  OFFICERS  OR  ENLISTED: 

Revised  MOS. . .  (indicate  any  current  or  new  ASI  or  SOI  here).  Draft  proposed  job  specifications 
are  attached  at  enclosure..,  .  Other  duties  and  tasks  are  listed  in  (AR  611-11 2,  AR  611-201). 

d.  If  a  new  MOS,  SSI,  ASI,  or  SOI  will  be  required  for  AR  611-101,  AR  611-112,  or  AR  611-201, 
use  the  following  for  each  MOS  and  SSI; 

FOR  COMMISSIONED  OFFICERS: 

New  SSI. . .  (indicate  any  SSI  here).  Draft  proposed  job  specifications  are  attached  at  enclosure. . 
FOR  WARRANT  OFFICERS  AND  ENLISTED; 

/ 

New  MOS. . .  (indicate  any  ASI  or  SQI  here).  Draft  proposed  job  specifications  are  attached  at 
enclosure. . .  . 

Note  8.  Provide  the  following  for  Paragraph  6: 

a.  NETP  number  (if  none,  so  state). 

b.  UlC,  quantity,  LIN,  nomenclature  and  justification  for  any  NET  Training  Base  requirements. 


Figure  2.  QQPRI  Format  (Conllnued). 
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The  combat  developer  within  the  TRADOC  proponent  school 
has  primary  responsibility  for  developing  the  BOIP  and 
QQPRI.  The  Program  Manager  within  the  Army  Materiel  Command 
(AMC)  subordinate  command  provides  input  to  the  combat 
developer.  DCSOPS  processes  and  approves  both  the  BOIP  and 
QQPRI . 

The  latest  version  of  AR  71-2  recognizes  that  the  Army 
HARDMAN  methodology,  as  the  Army's  current  manpower 
determination  aid,  feeds  the  BOIP/QQPRI  data.  But  AR  71-2 
also  leaves  room  for  additional  DCSPER-approved 
methodologies : 

"The  results  of  hardware  vs.  manpower  (HARDMAN) 
methodology  or  an  approved  DCSPER  methodology  will 
provide  source  data  for  the  BOIP  and  QQPRI  process." 
(Revised  AR  71-2,  10  Oct.  1986,  p.  10) 

The  MDA  will  probably  become  one  of  the  additional 
methodologies  cited  in  AR  71-2.  By  systematically  assessing 
workload,  the  MDA  will  provide  more  accurate  estimates  of 
manpower  requirements,  particularly  operator  requirements. 

Manpower  Assessment  in  Support  of  Requirements  Documents 

The  Letter  of  Agreement  (LOA)  and  Required  Operational 
Capability  (ROC)  both  have  sections  that  require  reporting  the 
results  of  a  "manpower/ force  structure  assessment."  TRADOC/AMC 
PAM  70-2  describes  this  assessment  as  follows: 

"Manpower/Force  Structure  Assessment.  Estimate 
manpower  requirements  per  system,  using  unit,  and  total 
Army  by  component  (Active,  ARNG,  USAR) .  Identify 
manpower  savings  resulting  from  replaced  systems,  if 
any.  Include  a  statement  to  require  an  assessment  of 
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alternatives  to  reduce  manpower  requirements  and  an 
assessment  of  force  structure  implications  resulting 
from  system  inclusion  in  the  total  force  by  component. 

If  the  force  structure  assessment  exceeds  current 
programmed  force  structure  levels,  then  identification 
of  force  structure  tradeoffs  within  mission  area  or 
mission  elements  is  required.  Tradeoffs  analysis  are 
addressed  to  the  degree  necessary  to  bring  the  force 
structure  assessment  within  current  programming  levels, 
if  possible.  The  personnel  support  package  will  be 
tested  during  OT  II . ” 


Manpower  Requirements  Determination  in  MANPRINT 

Currently,  there  are  two  major  sources  of  MANPRINT 
regulatory  information.  The  first  is  AR-602-2,  MANPRINT.  The 
second  is  the  Draft  chapter  on  MANPRINT  that  will  be  included  in 
the  revised  TRADOC/AMC  PAM  70-2,  Materiel  Acquisition  Handbook 
(hereafter  referred  to  as  the  revised  TRADOC/AMC  PAM  70-2) . 

According  to  AR  602-2  (p.  27) ,  "MANPRINT  data  to  support  the 
BOIP/QQPRI  shall  be  developed  during  the  Proof-of-Principle  Phase 
of  the  MAP.  This  regulation  also  cites  HARDMAN  and  (ECA)  as  two 
techniques  that  can  be  used  "as  inputs  to  the  BOIP  process"  (p. 
27)  . 

The  revised  AR  70-2  identifies  the  following  activities 
related  to  Manpower  Requirements  Determination  Aid  (p.  11.44  to 
11.76): 


2-15 


Requirements  and  Technology  Base  Activities  Phase 


o  Initiate  HARDMAN  and/or  EGA  early  in  this  phase 

Proof-of-Principle  Phase 
O  Conduct  HARDMAN 

o  Develop  input  to  BOIP/QQPRI 

o  Provide  input  to  ROC  on  the  "number  of  operators, 
maintainers,  and  repairers  the  new  equipment 
requires  in  each  unit.”  AR  70-2  describes  the 
manpower  requirements  information  to  be  included 
in  the  ROC. 

The  revised  version  of  TRADOC/AMC  PAM  70-2  provides 
additional  information  in  manpower  determination  related  to 
MANPRINT.  According  to  this  regulation,  the  DCD  -  Materiel  and 
Logistics  System  Division,  with  input  from  DOTD,  ARI,  and  AMC 
should  provide  input  to  Required  Operational  Capability  (ROC) . 

To  provide  this  input  this  organization  should  conduct  a  force 
structure  analysis  using  information  developed  in  the  organiza¬ 
tional  plan.  The  analysis  would  determine  the  number  of  pieces 
of  new  equipment  going  into  each  type  unit  and  the  number  of 
operators,  maintainers  and  repairers  the  new  equipment  requires 
in  each  unit.  They  should  also  identify  proposed  bill-payers  to 
ensure  a  zero  growth  in  the  force  structure,  if  the  number 
required  for  the  new  system  exceeds  the  number  available  from  the 
displaced  system. 

Table  1  provides  examples  of  the  manpower  and  personnel 
information  to  be  included  in  the  ROC. 
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Table  1 


Example  of  Manpower  and  Personnel  Information  to  be  Included  in 
ROC. 


This  is  an  example  of  Manpower /Force  Structure  Assessment  to  be 
included  in  the  ROC,  para  5a; 


"a.  Manpower/Force  Structure  assessment.  The  manpower  force 

structure  indicates  that  when  the  system  is  fully  fielded 
in  accordance  with  current  plans,  it  will  generate  the 
following  requirements: 


Crew 

Per 

System 


Crew 
System  & 
Support 
Per  Unit 


Total  Army 
Aggregate 

System  Support  Total 

(Other  Units)  Army 


OFF 

WO 

ENL 

Total  Army  personnel  resource  requirements  are: 


Actiye 
USAR  _ 
NG 


sayings/ increase  of 
sayings/increase  of 
sayings/ increase  of 
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Example  of  MANPRINT  manpower  and  personnel  assessments  to  be 
included  in  the  ROC,  para  8b; 

"b.  Personnel  Assessment. 

(1)  Crew  level  cannot  exceed  three  soldiers.  No 
maintenance  task  will  require  the  use  of  more  than  one 
soldier.  Maintenance  tasks,  when  compared  to  the 
predecessor  system,  will  be  decreased  by  20%  at  the 
unit  level. 

(2)  The  target  audience  description  lists  the  expected 
aptitude  levels  (ASVAB  scores)  of  the  soldiers  who  have 
tentatively  been  identified  as  the  operators  and 
maintainers  of  the  XM99. 
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2 . 4  USERS 


2.4.1  Overview  of  Users  and  Their  Functions 

Primary  Users.  Primary  MDA  users  will  be  the  Directorate  of 
Combat  Development  (DCD)  organization  within  the  TRADOC  proponent 
schools  responsible  for  developing  the  BOIP/QQPRI.  Usually,  this 
organization  will  be  the  Materiel  and  Logistic  System  Division. 
But  since  each  DCD  is  structured  somewhat  differently,  the 
responsible  organization  may  vary. 

Secondary  Users.  Another  major  MDA  user  will  be  the  program 
manager's  staff  within  the  AMC  subordinate  command  that  provides 
input  to  the  BOIP/QQPRI  development  process.  Usually  this  staff 
is  the  Logistics  Division  or  Group. 

Other  Users.  Other  potential  users  are  the  BOIP/QQPRI 
reviewers  such  as  HQ  TRADOC  (DCSOPS) ;  the  Organizational 
Integrator,  or  Force  Integration  Staff  Officer  (FISO) ;  and  the 
Soldier  Support  Center-National  Capitol  Region  (SSC-NCR) .  Other 
reviewers  include  HQ  AMC  (AMCDRE) ,  the  MANPRINT  Policy  Office 
within  ODCSPER  (DAPE-ZAM) ,  and  the  MANPRINT  points-of-contact 
within  the  TRADOC  proponent  schools  and  AMC  subordinate  command. 
The  ARI  field  office  representatives  who  may  provide  MANPRINT 
support  to  TRADOC  schools  or  AMC  subordinate  commands  are  also 
potential  users. 

2.4.2  Job  Type 

The  MDA  will  be  developed  specifically  for  the  primary  users 
listed  in  the  section  above.  These  primary  users  are  the  combat 
developers  within  the  TRADOC  proponent  school  who  produce  the 
BOIP/QQPRI.  The  individuals  who  actually  perform  these  functions 
within  the  assigned  DCD  division  are  typically  Army  majors  or 
captains. 
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2 . 5  Assumptions 


The  following  assumptions  underly  development  of  the  MDA: 

Major  System  Focus.  The  MDA  will  describe  manpower 
requirements  for  major  weapon  systems.  Although  the  general 
logic  of  the  MDA  applies  to  other  types  of  systems,  we  will 
develop  the  MDA's  automated  tools  only  for  major  systems. 

Difference  Between  Force  Structure  Analysis  and  Manpower 
Determination .  The  MDA  is  an  aid  for  determining  manpower.  It 
is  not  a  force  structure  analysis  tool.  A  manpower  determination 
analysis  determines  the  number  of  operators  and  maintainers 
needed  to  support  a  particular  weapon  system.  A  force  structure 
analysis  determines  the  size  and  composition  of  Army  units. 

Force  structure  analysis  considers  tasks  beyond  those  associated 
with  individual  weapon  systems.  It  also  assesses  the  impact  of 
personnel  and  equipment  attrition  during  wartime. 

Attrition  is  beyond  the  scope  of  manpower  determination  as 
described  an  Army  acquisition  documents.  As  a  result,  tools  such 
as  AMORE  that  deal  with  attrition  cannot  provide  a  basis  for 
manpower  determination. 

Operator /Maintainer  Differences  in  Manpower  Determination. 
The  basic  logic  underlying  determination  of  maintenance  and 
operator  manpower  requirements  is  the  same.  It  involves  dividing 
workload  demand  by  capacity.  However,  the  specific  elements  used 
to  calculate  them  are  quite  different.  Maintenance  manpower 
requirements  are  determined  by  computing  total  maintenance 
manhours  for  a  given  period  (usually  a  fairly  long  period  such  as 
a  year)  and  then  dividing  the  results  by  a  measure  of  capacity 
such  as  annual  available  maintenance  manhours.  Operator  or 
maintainer  workload  is  determined  by  examining 
cognitive/perceptual/physical  workload  at  particular  points  in 
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time  and  then  comparing  this  workload  with  the  human  capabilities 
for  dealing  with  it.  Our  approach  for  determining  manpower 
requirements  reflects  these  differences.  We  will  develop  network 
simulation  models  to  represent  both  operator  and  maintainer 
tasks . 

We  will  evaluate  operator  manning  based  on  a  workload  model 
that  McCracken  and  Aldrich  developed  (1984)^.  This  process  could 

also  be  used  to  determine  workload  for  maintainer  tasks  if  the 

* 

analyst  chooses  to  do  so.  The  primary  method  of  representing 
maintainer  tasks,  will  be  to  use  Micro  SAINT  networks. 

The  networks  resemble  the  ones  that  have  been  used  to  describe 
maintenance  performance  in  a  wide  range  of  studies.  Such  studies 
include  the  Coordinated  Human  Resource  Technology  and  the  Air 
Force  Logistic  Composite  Model  that  the  Air  Force  used  to 
determine  maintenance  manpower  requirements. 

Contractor  Inputs  to  MPA.  We  assume  that  the  prime 
contractor  will  provide  information  on  the  hviman  interface 
design.  This  information  includes  a  description  of  the  operation 
and  maintenance  of  all  major  system  components,  including  support 
equipment  (with  particular  emphasis  on  controls  and  displays) . 
Basically,  the  contractor  will  provide  the  level  of  information 
required  by  the  Type  B1  specification  of  Prime  Item  Development 
Specification  (see  MIL-STD-490) . 

The  MDA  will  not  require  information  on  system  tasks,  task 
performance  times,  or  accuracies  from  the  contractor.  The  MDA 
itself  will  provide  procedures  for  generating  these  information 
elements. 

Use  of  Army  Manpower  Algorithms  and  Allowances .  The  MDA 


^McCracken,  J.H.,  &  Aldrich,  T.B.  (1984).  Analysis  of 
selected  LHX  mission  functions;  Implications  for  operator 
workload  and  system  automation  goals  (ARI  Draft  Technical  Note) . 
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will  use,  without  modification,  the  basic  manpower  determination 
algorithm  for  variable  positions  in  AR  570-2.  It  will  also 
incorporate  the  work  capacity  factors  listed  in  AR  570-2  and  the 
Standards  of  Grade  Authorization  found  in  AR  611-201. 

Personnel  and  Training  Assumptions.  This  specification 
focuses  on  the  MDA's  initial  application.  In  this  first  applica¬ 
tion,  workload  estimates  are  based  on  an  assumption  that  (1) 
personnel  with  the  median  level  of  personnel  characteristics  (as 
determined  by  the  Personnel  Requirements  Estimation  Aid)  are 
performing  the  tasks,  and  (2)  the  type  and  amount  of  training 
these  personnel  have  received  is  that  which  is  most  likely  to  be 
assigned  (as  determined  by  the  Training  Constraints  Estimation 
Aid)  . 


The  MDA  will  be  iterated  in  subsequent  tradeoff  analyses  as 
part  of  the  application  of  the  MPT  Tradeoff  Analysis  Aid.  These 
tradeoffs  will  explore  different  assumptions  about  personnel  and 
training. 

Job  Determination.  The  MDA  will  help  identify  jobs.  The 
analysis  will  define  operator  jobs  by  assigning  specific  tasks  to 
duty  positions.  This  concept  is  congruent  with  the  Army's  Job 
Books  which  break  out  operator  tasks  by  duty  position.  After  the 
assignments  have  been  made,  the  MDA's  automated  steps  will  assess 
how  these  assignments  affect  workload  and  system  capability. 

Maintenance  jobs  are  defined  by  assigning  specific  tasks  to 
MOS/skill  level  combinations  at  particular  maintenance  levels. 

The  Army  does  not  have  duty  positions  for  maintainers.  The  MDA 
will  include  procedures  for  assigning  maintenance  tasks  to 
MOS/skill  level  combinations. 
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2.6  HIGH  LEVEL  FUNCTIONAL  REQUIREMENTS 


2.6.1  Technical  Requirements 

Outputs .  The  MDA  will  output  quantitative  manpower 
requirements,  by  job,  for  a  specific  contractor  design.  These 
manpower  requirements  will  include:  (1)  operator  manpower 
requirements,  (2)  maintenance  manpower  requirements,  and  (3) 
Direct  Productive  Annual  Maintenance  Manhours  (DPAMMH) . 

For  maintenance  the  MDA  will  also  be  capable  of  breaking  out 
manpower  requirements  by  MOS,  skill  level,  major  component  item 
(maintainers  only) ,  and  maintenance  level  (maintainers  only)  and 
will  be  capable  of  breaking  out  all  estimates  at  both  the  single 
system  and  aggregate  level. 

In  addition  to  producing  estimates  of  manpower  requirements, 
the  MDA  will  produce  estimates  of  system  availability, 
reliability,  and  operational  effectiveness.  These  estimates  will 
be  compared  with  the  requirements  for  these  criteria  identified 
by  the  System  Performance  Requirements  Estimation  Aid  (SPREA) 
identified  during  the  Requirements  Technology/Base  Activities 
phase  of  the  MAP.  Based  on  this  comparison,  shortfalls 
(discrepancies  between  requirements  and  estimates  based  on 
contractor  designs)  will  be  identified. 

Role  in  Accfuisition  Process.  The  MDA  information  on  manpower 
requirements  will  be  designed  to  feed  directly  into  the 
BOIP/QQPCI . 

Users.  The  MDA  will  be  specifically  designed  for  use  by  the 
combat  developers  within  the  TRADOC  proponent  school  who  produce 
the  BOIP/QQPRI  (see  Section  2.4.1). 
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2.6.2  Acceptability/Usability  Requirements 


The  previous  sub-section  presented  an  overview  of  the 
technical  requirements  that  must  be  met  by  the  MDA.  This  section 
describes  some  of  the  acceptability  and  usability  requirements 
which  also  must  be  met  by  these  tools. 

Produce  Tailored  User  Outputs  and  Processes.  Previous  R&D 
products  have  not  been  implemented  because  they  failed  to  meet 
the  needs  of  individual  Army  decision  makers.  They  were  R&D 
products  "in  search  of  users".  To  avoid  this  problem  in  the 
current  effort,  it  is  critical  that  specific  users  be  identified 
for  the  MDA.  Furthermore,  the  outputs  of  the  MDA  will  be 
formatted  so  that  Army  users  can  insert  them  directly  in  MAP 
documents.  Additionally  the  aids  will  be  capable  of  producing 
results  in  a  timely  fashion  and  be  capable  of  meeting  the 
requirements  of  the  new  streamlined  acquisition  process.  The 
latter  requirements  indicate  a  need  for  using  some  form  of 
automation  to  support  each  product  whenever  it  is  cost  effective 
to  do  so. 

Describe  "How  To"  Procedures.  Sufficient  "how  to" 
procedures  will  be  included  in  the  MDA  to  allow  Army  users  with 
minimal  training  to  apply  each  product.  Whenever  possible, 
procedures  will  be  automated  to  reduce  user  analysis 
requirements.  However,  for  all  automated  tools,  detailed 
procedures  for  obtaining  input  data  and  interpreting  results  will 
be  presented.  For  all  manual  tools,  detailed  instructions  for 
conducting  each  analytical  step  will  also  be  provided. 

Minimize  Organizational  Impacts.  The  MDA  will  be  designed 
to  fit  the  user  and  not  vice  versa.  Consequently,  they  will  not 
require  additional  personnel  to  apply  or  cause  restructuring  of 
existing  Army  organizations;  they  will  utilize  computer  hardware 
available  at  user  locations  or  accessible  via  secure  lines. 
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Minimize  User  Training.  The  members  of  the  MAP  community 
who  are  expected  to  be  users  of  the  MDA  are  already  overburdened 
and  understaffed.  In  addition,  they  are  trying  to  meet 
increasing  acquisition  requirements  such  as  MANPRINT  within  the 
context  of  the  streamlined  acquisition  process.  Consequently, 
training  time  for  the  (MPT)^  products  will  be  minimized.  This 
requires  development  of  user  interfaces  that  require  no  prior 
computer  experience.  For  example,  the  interface , contain  built-in 
job  aids  (e.g.,  help  commands).  Finally,  when  formal  training  is 
required,  it  will  be  developed  in  accordance  with  Army 
instructional  system  design  principles  and  utilize  only  media 
that  are  readily  available  or  accessible  to  users. 

Security.  The  MDA  may  be  required  to  accept  classified  data 
and  will  be  designed  to  provide  acceptable  levels  of  security. 


2.7  HARDWARE/SOFTWARE  CONFIGURATION 

The  hardware  system  that  the  MDA  will  be  installed  on 
consists  of  the  following  components: 

1.  Enhanced  graphics  display.  The  EGA  will  support  high 
resolution  color  graphics. 

2.  Enhanced  graphics  board  with  256K  bytes  RAM. 

3.  80286  processor 

4.  Hard  disk  with  a  minimum  of  20M  bytes  of  storage. 

5.  Up  to  4M  bytes  of  enhanced  memory. 

6.  Bernoulli  Box  or  its  functional  equivalent  with  two 
removable  20M  disks. 

7.  80287  Math  Coprocessor. 

8.  1200/2400  baud  Hayes-compatible  internal  modem. 

9.  One  or  more  floppy  drives  that  can  read  and  write  3 6 OK 
floppy  diskettes. 

10.  Dot  matrix  printer  capable  of  printing  132  characters 
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per  line.  This  printer  will  be  capable  of  outputting 
IBM  graphics. 

11.  IBM  AT-compatible  keyboard. 

The  MDA  software  will  be  developed  under  the  most  recent 
version  of  Microsoft  C.  At  the  present  time,  the  operating 
system  for  the  software  will  be  DOS  3.2. 

The  data  libraries  in  the  MDA  will  be  built  using  R-Base  V. 
We  will  sort,  retrieve,  and  store  information  in  these  files 
using  code  developed  in-house  via  dbC  Library  routines.  These 
library  functions  do  not  require  any  licensing  fees  and  will  be 
fully  integrated  into  the  MDA  code. 
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SECTION  3  -  STEPS  IN  APPLYING  THE  MDA 


As  was  proposed  in  the  concept  paper  and  outlined  in  section 
2  of  this  design  specification,  the  MDA  consists  of  two 
distinctly  different  software  tools  that  the  analyst  will  use  to 
estimate  the  manpower  requirements  for  a  proposed  new  system. 

The  Maintenance  Manpower  Analysis  Aid  (MMAA)  will  allow  the  user 
to  analyze  the  manpower  required  to  maintain  a  proposed  new 
system  in  terms  of  the  maintenance  jobs  required  (MOS/Skill 
levels) ,  the  number  and  types  of  maintenance  tasks  that  must  be 
performed  by  each  maintenance  job,  the  maintenance  manhours 
required  for  each  job,  and  an  estimate  of  the  headcount  required 
for  each  maintenance  job. 

The  Workload  Assessment  Aid  (WAA)  will  guide  the  user 
through  the  process  of  assessing  the  manpower  requirements  of  a 
proposed  new  system  by  estimating  the  workload  requirements  of  a 
proposed  staffing  plan  for  opiating  the  system  or  for  performing 
maintenance  activities. 

This  section  will  describe  the  global  keystroke 
specifications  and  the  user  actions  that  are  that  are  generic  to 
all  of  the  activities  that  users  will  perform  in  using  the  MDA. 
These  generic  specifications  are  followed  by  the  detailed 
specifications  that  are  specific  for  each  of  the  steps  within  the 
MMAA  and  the  WAA. 

Since  the  steps  associated  with  each  of  the  analysis  aids 
are  so  distinctly  different,  we  have  used  a  different  numbering 
scheme  for  the  two  sets  of  steps.  The  steps  in  the  MMAA  are 
numbered  1 . 1  through  1.8.  Steps  in  the  WAA  are  numbered  2 . 1 
through  2.11. 
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The  first  step  in  using  either  the  MMAA  or  the  WAA  is  to 
identify  the  system  that  is  to  be  evaluated.  Therefore,  the 
process  for  performing  step  0  will  be  described  before  the 
description  of  the  MMAA  or  WAA  steps. 

The  description  of  each  step  is  organized  into  the  following 
parts : 

1..  Input  -  the  data  that  is  required  for  the  completion  of 
the  step.  There  are  two  types  of  input  data, 
o  External  -  inputs  obtained  from  sources  external 
to  the  MDA 

o  Internal  -  data  that  is  obtained  from  sources  that 
are  included  within  the  MDA. 

2 .  Process  -  a  general  description  of  the  process  that  the 
user  will  follow  to  perform  the  step.  Included  in  the 
process  description  is  a  detailed  flow  diagram  of  the 
actions  the  user  will  follow. 

3 .  Output  -  the  data  that  will  be  generated  as  a  result  of 
the  step. 

4 .  User  Interface  -  a  description  of  the  way  the  user  will 
be  prompted  and  the  way  the  user  will  respond 
throughout  the  performance  of  the  step.  This  is  a  very 
detailed  discussion  of  each  screen  the  user  will  see  as 
a  result  of  his  or  her  input. 
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3.1  GLOBAL  KEYSTROKE  SPECIFICATIONS 


Following  is  a  list  of  the  general  specifications  for  the 
functionality  of  global  function  and  editing  keys  for  the  Product 
5  Manpower  Determination  Aid. 

FUNCTION  KEYS 

FI  Help  -  This  key  will  always  switch  the  system  into  the 
help  mode.  When  this  key  is  pressed,  the  system  will 
display  the  first  page  of  context  specific  help 
information  explaining  the  current  menu,  screen,  or 
prompt . 

Shift  FI  Help  Index  -  When  the  FI  function  key  is  pressed  while 
holding  down  the  shift  key,  the  user  is  presented  with 
an  index  of  help  information. 

F2  Move-bv-cell/Edit  toggle  -  This  key  controls  the 

function  of  the  arrow  cursor  keys  when  the  user  is 
working  in  a  spreadsheet-like  template.  In  the  default 
state,  the  arrow  keys  will  move  the  cursor  from  cell  to 
cell  in  the  template.  When  the  F2  key  is  pressed,  or 
when  the  user  begins  to  type,  the  system  switches  into 
the  "Edit”  mode  and  the  arrow  keys  move  the  cursor 
character  by  character  (left  and  right)  or  line  by  line 
(up  and  down)  within  a  cell.  If  the  cursor  is  in  the 
first  character  position  of  a  cell  and  the  left  arrow 
is  pressed,  or  if  the  cursor  is  in  the  topmost  line  of 
a  particular  cell  and  the  up  arrow  is  pressed,  the 
system  will  beep.  The  user  can  terminate  an  edit 
operation  and  return  to  the  "Move-by-cell"  state. 
Repeated  pressing  of  the  F2  key  will  toggle  between  the 
move-by-cell  and  move-by-character  states. 
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F3  Search  -  When  this  key  is  pressed,  the  user  will  be 

prompted  for  a  string  of  characters  or  keystrokes  that 
the  system  will  search  for.  The  string  of  keystrokes 
is  terminated  by  pressing  the  F3  key  a  second  time. 
After  terminating  the  string,  the  system  will  search 
the  current  library,  template,  or  list  for  a  match  for 
the  input  string.  If  a  match  is  found,  the  cursor  is 
moved  to  the  matched  input  string.  If  no  match  is 
found,  the  cursor  remains  where  it  is  and  a  message 
indicating  no  match  found  is  displayed. 

At  times  when  the  F3  key  is  not  active,  the  user  will 
receive  a  message  indicating  such. 

F4  NOT  USED  AT  THIS  TIME 

F5  NOT  USED  AT  THIS  TIME 

F6  NOT  USED  AT  THIS  TIME 

F7  NOT  USED  AT  THIS  TIME 

F8  NOT  USED  AT  THIS  TIME 

F9  Menu  -  Displays  the  active  menu  bar  while  working  in  a 
spreadsheet-like  template.  This  key  uses  a  "toggle” 
type  of  functionality.  When  the  commands  on  a  menu  bar 
are  displayed,  the  cursor  moves  from  command  to  command 
within  the  menu  bar.  When  the  menu  bar  commands  are 
not  displayed,  the  cursor  moves  around  within  the 
current  template. 

FIO  Save  -  Saves  the  current  working  file  to  the 

appropriate  permanent  file  then  returns  to  the  current 
working  status.  NOTE:  The  "save"  command  may  also 
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EDIT  KEYS 

ESC 

Shift  ESC 

Backspace 

Return 

Caps  Lock 

Ins 


appear  on  a  menu  bar  when  it  is  appropriate  save  at  the 
end  of  an  activity  or  procedure.  However,  in  order  to 
make  it  easy  for  a  user  to  save  early  and  often,  this 
key  is  also  always  active. 


cruit  -  Always  returns  to  the  most  recent  previous  state 
such  as  the  most  recent  menu,  screen,  or  prompt. 

super  quit  -  Always  returns  to  the  MDA  main  menu.  If 
changes  have  been  made  to  the  current  working  file,  the 
user  will  be  prompted  to  save  or  cancel  changes . 

This  key  is  only  active  when  the  system  is  allowing  for 
input  by  the  user.  The  backspace  key  moves  the  cursor 
one  space  to  the  left  of  its  current  position  and 
erases  any  character  from  that  position. 

Terminates  variable  length  user  input.  If  the  user  is 
currently  working  in  a  spreadsheet-like  template, 
entering  the  return  key  changes  the  state  of  cursor 
movement  from  move-by-character  to  move-by-cell. 

Toggles  the  keyboard  from  a  normal  state  to  one  that 
displays  characters  as  if  the  shift  key  was  being  held 
down.  When  the  keyboard  is  in  the  ''Caps  Lock”  state 
and  the  user  holds  down  the  shift  key  while  pressing 
another  key,  the  normal  (non-shift)  character  displays. 

Insert  -  Toggles  the  system  from  character  insert  for 
user  input  to  typeover.  When  the  state  is  character 
insert,  the  characters  input  by  the  user  are  inserted 
to  the  left  of  the  current  cursor  position.  When  the 
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Del 


Home 


End 


PgUp 


PgDn 


state  is  typeover,  characters  are  displayed  at  the 
current  text  cursor  position.  Any  characters  currently 
displayed  at  that  position  will  be  replaced. 


Delete  -  Deletes  characters  that  are  displayed  at  the 
current  text  cursor  position. 

Moves  the  menu  cursor  to  the  top  or  the  left  most  menu 
selection.  Moves  the  cell  cursor  to  the  upper  left 
corner  of  a  spreadsheet-like  template.  Moves  the  text 
cursor  to  the  upper  left  most  typing  position  of  the 
current  input  area  (i.e.,  cell,  field,  etc.).  See 
cursor  definitions  below. 

The  end  key  works  the  exact  opposite  of  the  home  key. 

It  moves  the  menu  cursor  to  the  bottom  or  the  right 
most  menu  selection.  It  moves  the  cell  cursor  to  the 
lower  left  corner  of  a  spreadsheet-like  template.  It 
moves  the  text  cursor  to  the  lower  right  most  typing 
position  of  the  current  input  area.  See  cursor 
definitions  below. 

Page  Up  -  If  the  cursor  (menu,  text,  of  cell)  position 
is  not  at  the  top  of  the  current  visible  display  or 
window,  the  cursor  is  moved  to  that  position.  If  the 
cursor  position  is  at  the  top  of  the  current  visible 
display  or  window,  the  cursor  is  moved  to  the  top  of 
the  previous  full  screen  or  window-full  of  information. 

Page  Down  -  If  the  cursor  (menu,  text,  or  cell) 
position  is  not  at  the  bottom  of  the  current  visible 
display  or  window,  the  cursor  is  moved  to  that 
position.  If  the  cursor  position  is  at  the  bottom  of 
the  current  visible  window,  the  cursor  is  moved  to  the 
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bottom  of  the  next  full  screen  or  window-full  of 
information. 

Up  Arrow  -  Moves  the  cursor  (menu,  text,  or  cell)  up 
one  position  (line  or  cell) . 

Down  Arrow  -  Moves  the  cursor  (menu,  text,  or  cell) 
down  one  position  (line  or  cell) . 

Left  Arrow  -  Moves  the  cursor  left  one  position 
(character  or  cell) . 

Right  Arrow  -  Moves  the  cursor  right  one  position 
(character  or  cell) . 

Ctrl  Up  Arrow  -  Moves  the  cursor  (menu,  text,  or  cell) 
up  one  full  screen  or  window-full  of  information  to  its 
same  relative  horizontal  position. 

Ctrl  Down  Arrow  -  Moves  the  cursor  down  one  full  screen 
or  window-full  of  information  to  its  same  relative 
horizontal  position. 

Ctrl  Left  Arrow  -  Moves  the  cursor  to  the  left  by  one 
screen  or  window-full  of  information  to  its  same 
relative  vertical  position. 

Ctrl  Right  Arrow  -  Moves  the  cursor  to  the  right  by  one 
full  screen  or  window-full  of  information  to  its  same 
relative  vertical  position. 
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CURSOR  TYPES 

Text  Cursor  Indicates  the  typing  position  for  user  input  of 
information.  The  text  cursor  is  a  flashing 
underscore  character. 

Menu  Cursor  Highlights  a  menu  option.  The  menu  cursor  can  be 
moved  in  appropriate  direction  with  the  arrow  keys 
on  the  numeric  key  pad. 

Cell  Cursor  Highlights  an  entire  cell  in  a  spreadsheet-like 
template  to  indicate  which  cell  any  subsequent 
activity  will  take  place.  The  arrow  keys  move  the 
cell  cursor  from  cell  to  cell  in  the  direction  of 
the  arrow. 

3.2  MENU  TYPES  AND  SELECTION  STRATEGIES 

Menu  Bars  Display  at  the  top  of  the  screen.  The  exception 

to  this  is  the  menu  bar  that  displays  at  the 
bottom  of  help  screens.  Menu  bars  contain  a 
horizontally  displayed  list  of  command  verbs.  To 
select  a  command  verb  from  a  menu  bar,  you  either 
press  the  fist  letter  of  the  command  you  want  to 
issue  or  move  the  menu  cursor  with  the  left  and 
right  arrow  keys  to  the  desired  command  and  then 
press  the  RETURN  key.  The  cursor  on  a  menu  bar 
will  wrap  from  the  last  command  to  the  first  and 
vice  versa. 

When  a  command  is  highlighted  on  a  menu  bar,  a 
brief  description  of  that  option  is  displayed  on 
the  line  directly  below  the  horizontal  list  of 
menu  options. 
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Pop-Up  Menus  There  are  two  levels  of  pop-up  menus.  The  first 
level  is  a  direct  result  of  selecting  a  command 
from  a  menu  bar  or  from  a  main  flowchart  menu  that 
displays  at  the  beginning  of  the  MDA,  the  MMAA,  or 
the  WAA  (see  description  below) .  The  second  level 
of  pop-up  menus  display  overlapped  on  the  first 
level  and  are  a  direct  result  of  a  selection  from 
the  first  level  menu. 

Menu  items  on  a  pop-up  menus  consist  of  either 
activity  areas  you  select  to  work  in  or  items  from 
a  taxonomy,  library,  or  other  list  that  you  can 
select. 

There  will  be  a  maximum  of  ten  possible  selections 
displayed  on  a  pop-up  menu.  Each  selection 
position  will  be  numbered  0-9.  If  there  are  more 
items  in  the  list  than  will  fit  into  one  of  the 
selection  positions,  the  user  will  be  able  to 
scroll  or  page  through  the  list  with  arrow  keys. 

There  are  two  ways  that  you  can  select  an  item 
from  a  pop-up  menu.  You  can  press  the  key 
corresponding  to  the  position  number  displayed 
next  to  the  option  you  desire.  You  can  move  the 
menu  cursor  to  the  option  you  want  to  select  with 
the  up  and  down  arrow  keys  and/or  the  PgUp  and 
PgDn  keys  and  then  press  the  RETURN  key. 

Some  pop-up  menus  may  be  displayed  with  command 
verbs  shown  at  the  bottom  of  the  pop-up  window. 
Commands  appear  on  the  pop-up  menu  (rather  than  on 
the  menu  bar)  when  the  actions  that  they  invoke 
apply  only  to  the  current  pop-up  menu.  For 
example,  in  may  be  necessary  to  insert  a  new  item 
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into  a  list  that  displays  in  a  second  level  pop-up 
menu.  In  this  case,  if  the  "insert”  command 
appeared  at  the  bottom  of  the  second  level  pop-up 
menu. 

The  procedure  for  selecting  a  command  from  a  pop¬ 
up  menu  is  the  same  as  for  selecting  a  command 
from  a  menu  bar. 

Pressing  the  ESC  key  always  returns  control  to  the 
previous  menu  or  prompt. 


3.3  GENERIC  COMMAND  DESCRIPTIONS 


Following  is  a  list  of  descriptions  of  commands  whose 
general  functionality  is  consistent  throughout  the  MDA.  Commands 
that  are  specific  to  an  individual  step  are  described  in  the 
discussion  of  the  screens  that  apply  to  that  step. 

select  The  select  command  is  used  in  two  slightly  different 
contexts.  However,  its  use  is  consistent  throughout 
the  MDA.  When  the  select  command  is  displayed  at  the 
bottom  of  a  first  level  pop-up  menu  with  the  type-in  as 
the  other  command  option,  it  means  "I  want  to  select  an 
entry  for  the  highlighted  field  from  a  list  of 
options" .  When  the  select  command  is  displayed  at  the 
bottom  of  a  list  of  options  select  means  to  choose  the 
highlighted  option.  When  the  pop-up  menu  consists  of  a 
list  of  options  and  there  are  no  commands  displayed, 
the  user  can  issue  an  implicit  "select"  command  by 
highlighting  the  desired  option  and  pressing  the 
<ENTER>  key  or  by  pressing  the  number  of  the  desired 
option. 
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insert 


This  command  lets  the  user  "insert"  a  new  item  into  a 
list  of  options  such  as  a  new  functional  system  or  a 
new  Mission/Condition  Set  file  name.  To  perform  the 
"insert"  operation,  the  user  highlights  the  option 
before  the  position  where  the  insert  is  to  occur. 

Then,  when  the  insert  command  is  issued  by  highlighting 
it  and  pressing  <ENTER>  or  by  pressing  the  "i"  key,  a 
new  position  opens  up  in  the  list  with  a  flashing 
cursor  prompting  the  user  to  enter  a  new  name.  After 
the  new  name  has  been  entered,  the  system  will  behave 
as  if  a  "modify"  command  had  been  issued  (see  below) . 

modify  When  this  command  is  available,  it  lets  the  user  modify 
parameters  that  are  associated  with  a  given  option. 

For  example,  in  many  cases  a  menu  will  contain  a  list 
of  template  names  such  as  the  list  of  function 
templates.  When  the  user  chooses  the  modify  command  he 
or  she  will  be  able  to  enter  or  modify  information 
contained  in  the  highlighted  template  name. 

copy  This  command  lets  the  user  "copy"  an  item  in  a  list  of 

options  such  as  a  functional  system  or  a 
Mission/Condition  Set  file  name.  When  an  item  is 
copied,  all  of  the  parameters  or  information  associated 
with  that  item  will  also  be  copied.  To  perform  the 
"copy"  operation,  the  user  highlights  the  option  to  be 
copied.  Then,  when  the  copy  command  is  issued  by 
highlighting  it  and  pressing  <ENTER>  or  by  pressing  the 
"C"  key,  a  new  position  opens  up  in  the  list  with  a 
flashing  cursor  prompting  the  user  to  enter  a  new  name. 

delete  In  the  general  sense,  this  command  lets  the  user  delete 
an  item  and  all  of  its  associated  parameters  and 
information  from  a  list  of  options.  When  the  delete 
command  is  issued,  the  user  will  be  presented  with  a 
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message  notifying  that  data  will  be  lost  if  the  delete 
is  executed.  When  this  message  is  displayed,  the  user 
will  be  required  to  verify  or  cancel  the  delete 
operation.  Any  specific  functionality  for  the  delete 
command  that  differs  from  this  definition  will  be 
described  in  the  discussion  of  the  screens  that  apply 
to  that  procedure. 


3 . 4  STEP  0  -  Enter  the  MDA  and  Identify  the  System  to  be 
Evaluated. 

In  this  step,  the  user  will  gain  access  to  the  Manpower 
Determination  Aid.  From  the  first  level  of  MDA  interfaces,  users 
will  indicate  whether  they  want  to  begin  an  analysis  of  a  new 
system  or  resume  work  on  an  analysis  already  in-progress. 

Whether  beginning  a  new  analysis  or  resuming  work  on  an  existing 
analysis,  the  analysis  must  begin  by  identifying  the  system. 

3 . 4 . 0 . 1  Input 

External ;  The  external  input  to  this  step  is  a  set  of  System 
Files  and  Mission/Condition  Set  Files  obtained 
from  a  Product  1  SPREA  Analysis  (if  available) . 

Internal ;  The  internal  inputs  for  this  step  are  the 
taxonomies  for  Mission  Areas,  System  Types, 

Generic  Functional  Systems,  and 
Mission/Conditions. 

3 . 4 . 0 . 2  Process 

The  user  will  begin  by  accessing  the  MDA  software  from  his 
or  her  computer  system.  This  will  be  accomplished  by  simply 
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booting  up  the  operating  system  and,  at  the  operating  system 
prompt ,  entering :  MDA 

Once  the  user  has  gained  access  to  the  MDA  software,  he  or 
she  will  specify  whether  to  begin  an  analysis  for  a  new  system, 
resume  an  in-progress  analysis  or  gain  access  to  the  MDA 
utilities. 

If  the  user  chooses  to  begin  a  new  analysis,  the  MDA 
software  will  guide  him  or  her  through  a  complete  identification 
of  the  system  to  be  analyzed.  This  will  include  identifying  the 
Mission  Area,  System  Type,  System  Name,  and  Mission/Conditions 
for  the  MDA  analysis.  When  the  user  is  beginning  a  new  analysis, 
he  or  she  will  also  be  able  to  choose  whether  to  select  the 
system  from  a  Product  1  SPREA  analysis  or  to  identify  a  new 
system  from  scratch. 

If  the  user  is  resuming  work  on  an  existing  system  under 
evaluation,  he  or  she  will  only  need  to  specify  the  system  name 
and  the  Mission/Condition  set  file  name  to  identify  the  system. 

The  flow  diagrams  of  the  process  of  performing  step  0  are 
included  on  the  following  pages. 
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STEP  -  0  Identify  System 
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STEP  -  0  Identify  System 

page  4  of  9 
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Mission  Field 


Product  5 
Mission 
Taxonomy 


~  0  Identify  System 

page  5  of  9 
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STEP  -  0  Idem 

page  6  of  9 
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System 


STEP  -  0 

page  7  of 


Identify  System 
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STEP  -  0  Identify  System' 

page  8  of  9 
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3 . 4 . 0 . 3  Output 


The  output  of  this  step  is  the  creation  of  a  file  that 
identifies  the  system  for  future  I/O  activities  and  the  creation 
of  a  Mission/Condition  set  file  that  describes  the  mission  for 
the  current  analysis  and  conditions  under  which  that  mission  will 
be  analyzed. 

3. 4. 0.4  User  Interface 

The  user  interfaces  that  apply  to  this  step  are  described  in 
detail  on  the  following  pages.  Please  note  that  all  screens  for 
step  0  are  labeled  "Screen  O.X”. 

Screen  0.1  -  Access  the  Manpower  Determination  Aid  by  typing 

"MDA”  at  the  operating  system  prompt  (C>_) . 

This  is  the  Manpower  Determination  Aid  Title  Screen. 

User  Action: 

<SPACE  BAR>  This  is  the  only  accepted  input  with  the 

exception  of  FI  (help) .  The  system  displays 
screen  0.2. 
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MANPOWER  DETERM I NATION  AID 


F"'  r-  B  B  B  t  f-j  e  S  F“‘  f --i  C  E  B  A  F^  t  c:*  b  e  r;i  i  n 


Screen  0.1  - 


Access  the  Manpower  Determination  Aid  by  typing 
"MDA"  at  the  operating  system  prompt  (C>_). 
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Screen  0.2  -  Manpower  Determination  Aid  Main  Menu. 

User  Action: 

The  user  can  take  generic  menu  selection  proceSures  to 
select  one  of  the  items  on  the  menu.  If  the  user  presses 
the  <ESC>  key,  screen  0.1  will  display. 

1.  Begin  Analysis  -  When  the  user  selects  this  option, 
screen  0.3  displays. 

2.  Resume  Analysis  -  When  the  user  selects  this  option, 
screen  0.3  displays. 

3.  Utilities  -  When  the  user  selects  this  option,  screen 
0.59  displays. 

<ESC>  -  Displays  screen  0.1. 
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MAMPOWE DETERM  I  MPT  I QM  P I D 
MPIN  MENU 


1.  Bey  in  Pna lysis 
£-  Resume  Pna lysis 
3.  Utilities 


Screen  0.2  -  Manpower  DeterminaticM  Aid  Mam  Menu. 
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Screen  0-3  -  Flowchart  Menu  for  the  MDA 


This  screen  is  a  menu  of  the  activities  that  the  user  can 
select  from  within  the  MDA.  The  way  that  the  menu  is 
displayed  also  serves  as  a  flowchart  of  the  sequence  in 
which  the  activities  should  be  performed.  The  flowchart 
shows  that  the  "Identify  System"  option  must  be  performed 
before  selecting  either  the  MMAA  or  the  WAA.  Once  the 
system  has  been  identified,  the  user  can  select  either  the 
MMAA  or  the  WAA  as  the  next  option.  The  user  can  select  an 
item  from  the  flowchart  menu  by  using  one  of  the  normal 
(generic)  menu  selection  procedures; 

1.  Highlight  the  desired  option  using  the  up,  down, 
left,  right  arrow  keys  and  then  press  <ENTER>. 

2.  Enter  the  number  of  the  desired  option. 

User  Actions; 

1.  Identify  System  -  If  the  user  previously  chose  to  begin 
a  new  analysis,  the  next  screen  is  0.5.  If  the  user 
chose  to  resiame  an  analysis  already  in-progress,  the 
next  screen  is  0.50. 

2 .  Maintenance  Manpower  Analysis  Aid  -  if  this  option  is 
selected  and  the  system  has  not  been  identified,  the 
next  screen  is  0.4.  If  the  system  has  been  identified, 
the  next  screen  is  1.0. 

3 .  Workload  Analysis  Aid  -  if  this  option  is  selected  and 
the  system  has  not  been  identified,  the  next  screen  is 
0.4.  If  the  system  has  been  identified,  the  next 
screen  is  2.0. 

<ESC>  -  Returns  the  user  to  screen  0.2. 


3-27 


MODE:  MDh> 


MODE:  WovS 


F-L014CHPRT  FDR  THE  MhNPGWER  DETERM  I  NhT  I  ON  HID 
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and  then  pv^ess  <ENTER> 
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1 

1 

i 

Screen  0-3  -  Flowchart  Menu  for  the  MDA 
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Screen  0.4  -  Error  Message. 


The  user  has  chosen  to  access  the  MMAA  or  the  WAA  without 
first  identifying  the  system. 

User  Action; 

The  only  acceptable  user  action  from  this  screen  is  to  press 
the  <ENTER>  key.  Next  screen  is  0.3. 
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iviGDE:;:  MDP> 


MODE:  Uor[ 


FLOWCHART  FOR  THE  HANPGWER  DETERM I NAT I ON  AID 
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Screen  0.4  Error  Message 
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Screen  0.5 


Identify  System  Menu. 


Lets  the  user  choose  to  identify  a  system  for  which  a 
Product  1  SPREA  analysis  was  performed  or  identify  an 
entirely  new  system  from  scratch. 

User  Action; 

1.  Select  system  from  SPREA  analysis.  Next  screen  is  0.6. 

2.  Identify  new  system.  Next  screen  is  0.6 
<ESC>  -  Returns  the  user  to  screen  0.3. 
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PPiT H  s  HDP >  I  d  S vst  ern > 


MODE:  Work 


IDENTIFY  SYSTEM 


1.  Select  syetern  from  SPREA  analysis 
E-  Identify  new  system 


Screen  0.5  -  Identify  System  Menu. 
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Screen  0.6  -  System  Description  Menu. 

From  this  menu,  the  user  will  identify  the  Mission  Area, 
System  Type,  System  Name,  and  Mission/ Condition  Set  for  the 
system  under  evaluation.  If  the  user  is  selecting  a  system 
from  a  SPREA  analysis,  the  System  Name  and  Mission/Condition 
Set  name  will  come  from  Product  1  SPREA  files. 

The  fields  on  the  System  Description  menu  must  be  entered  in 
order.  For  example,  if  the  user  selects  the  System  Type 
field  and  the  Mission  Area  has  not  been  identified,  an  error 
message  will  be  displayed. 

User  Actions; 

1.  Mission  Area.  Next  screen  0.7. 

2.  System  Type.  If  the  Mission  Area  has  been  defined,  the 
next  screen  is  0.9.  If  the  Mission  Area  has  not  yet 
been  defined,  an  error  message  displays. 

3.  System  Name.  If  the  Mission  Area  and  the  System  type 
have  been  defined,  and  the  user  has  previously  chosen 
to  select  a  system  from  a  Product  1  SPREA  analysis,  the 
next  screen  will  be  0.11.  If  the  Mission  Area  and  the 
System  Type  have  been  defined,  and  the  user  has  chosen 
to  identify  a  new  system  entirely  from  scratch,  the 
next  screen  will  be  0.22.  If  the  Mission  Area  or 
System  Type  have  not  yet  been  defined,  an  error  message 
displays. 

4.  Mission/Condition  Set  Name.  If  the  Mission  Area,  the 
System  Type,  and  the  System  Name  have  been  defined,  and 
the  user  has  previously  chosen  to  select  a  system  from 
a  Product  1  SPREA  analysis,  the  next  screen  will  be 
0.11.  If  the  Mission  Area,  System  Type,  and  System 
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Name  have  been  defined,  and  the  user  has  chosen  to 
identify  a  new  system  entirely  from  scratch,  the  next 
screen  will  be  0.24.  If  the  Mission  Area,  System  Type, 
and  System  Name  have  not  yet  been  defined,  an  error 
message  displays. 

<ESC>  -  Returns  the  user  to  screen  0.5. 
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hlDhl)  Id  System) 


MODE  s 


SYSTEM  DESCRIPTION 

_ _ 

i. 

Mission  Area : 

iZ.  m 

System  Ty(De: 

3» 

System  Name: 

4. 

M i Bs i on / Cond i t i ons  Set  Name  s 

Screen  0.6  - 


System  Description  Menu. 


Wof'k 
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Screen  0.7  -  Mission  Area  List.  From  this  list,  the  user  will 
select  a  Mission  Area  for  the  system  under 
evaluation . 

User  Action; 

The  user  will  select  a  Mission  Area  from  the  list  using 
normal  menu  selection  procedures.  Next  screen  0.8. 

<ESC>  -  Returns  the  user  to  screen  0.6. 


Input  File; 

Product  5  Mission  Area/System  Type  Taxonomy 


PATHn  h1DA>j:d  System) 


MODE:  Work 


SYSTEM  DESCR I PT I ON 


1.  Mission  Areas 
E-  System  Type: 

3-  System  Name: 

4.  Mission/Cond i t ions  Set  Name: 


Mission  Av^ea 

List 

1. 

Air  Defense 

2- 

Av i at  ion 

a 

Combat  Service  Support 

4. 

Close  Combat 

Li  ght 

5. 

Close  Combat 

Heavy 

6- 

Fire  Support 

Screen  0.7  -  Mission  Area  List.  From  this  list,  the  user  will 
select  a  Mission  Area  for  the  system  under 
evaluation. 
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Screen  0.8  -  System  Description  Menu  with  Mission  Area 
selected. 

From  this  screen,  the  user  can  select  the  System  Type  field. 

User  Action! 

1.  Mission  Area.  Next  screen  0.7. 

2.  System  Type.  Next  screen  0.9. 

3.  System  Name.  If  the  Mission  Area  and  the  System  type 
have  been  defined,  and  the  user  has  previously  chosen 
to  select  a  system  from  a  Product  1  SPREA  analysis,  the 
next  screen  will  be  0.11.  If  the  Mission  Area  and  the 
System  Type  have  been  defined,  and  the  user  has  chosen 
to  identify  a  new  system  entirely  from  scratch,  the 
next  screen  will  be  0.22.  If  the  Mission  Area  or 
System  Type  have  not  yet  been  defined,  an  error  message 
displays. 

4.  Mission/ Condition  Set  Name.  If  the  Mission  Area,  the 
System  Type,  and  the  System  Name  have  been  defined,  and 
the  user  has  previously  chosen  to  select  a  system  from 
a  Product  1  SPREA  analysis,  the  next  screen  will  be 
0.11.  If  the  Mission  Area,  System  Type,  and  System 
Name  have  been  defined,  and  the  user  has  chosen  to 
identify  a  new  system  entirely  from  scratch,  the  next 
screen  will  be  0.24.  If  the  Mission  Area,  System  Type, 
and  System  Name  have  not  yet  been  defined,  an  error 
message  displays. 


<ESC>  -  Returns  the  user  to  screen  0.5. 


•'  f)  T  H  s  M  D  A  >  I  d  S  y  B  t  e  rn  > 


MODE:  Wov-k 


SYSTlEkl  DESCRIPTION 


I.  Mission  Areas  Aviation 
E.  System  Type: 

3.  System  Names 

4.  Mi SB i on/Gond i t i ons  Set  Name  s 


Screen  0.8  - 


System  Description  Menu  with  Mission  Area 
selected. 


3-39 


Screen  0.9 


Aviation  System  Types  List. 


From  this  list  the  user  will  select  a  System  Type  category 
for  the  system  under  evaluation. 

User  Action; 

The  user  will  use  normal  menu  selection  procedures  to  choose 
a  System  Type  from  the  list.  Next  screen  0.10. 

<ESC>  -  Returns  the  user  to  screen  0.8. 

Input  File: 

Product  5  Mission  Area/System  Type  Taxonomy. 
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'•PTH  2  MDP  >  I  cl  S yst  em > 


MODE:  Work 


SYSTEM  DESCRIPTION 

1-  Mission  Prea :  Pviation 

S.  System  Type: 

3.  System  Name: 

4«  Mission/Cond i t ions  Set  Name: 

Pviation  System  Types 

Ik  Pttack  Helicopters 

E-  Cargo  Helicopters 

3-  Utility  Helicopters 

4-  Scout  Helicopters 

Other  Helicopters 

S.  Fixed  Wing 

1 

! 

1 

Screen  0.9  -  Aviation  System  Types  List. 
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Screen  0.10  -  System  Description  menu  with  Mission  Area  and 
System  Type  selected. 

From  this  screen,  the  user  can  select  the  System  Name  field 

or  either  of  the  previously  identified  fields. 

User  Action; 

1.  Mission  Area.  Next  screen  0.7. 

2.  System  Type.  Next  screen  0.9. 

3.  System  Name.  If  the  user  has  previously  chosen  to 
select  a  system  from  a  Product  1  SPREA  analysis,  the 
next  screen  will  be  0.11.  If  the  user  chose  to 
identify  a  new  system  entirely  from  scratch,  the  next 
screen  will  be  0.22. 

4.  Mission/Condition  Set  Name.  If  the  Mission  Area,  the 
System  Type,  and  the  System  Name  have  been  defined,  and 
the  user  has  previously  chosen  to  select  a  system  from 
a  Product  1  SPREA  analysis,  the  next  screen  will  be 
.0.11.  If  the  Mission  Area,  System  Type,  and  System 
Name  have  been  defined,  and  the  user  has  chosen  to 
identify  a  new  system  entirely  from  scratch,  the  next 
screen  will  be  0.24.  If  the  Mission  Area,  System  Type, 
and  System  Name  have  not  yet  been  defined,  an  error 
message  displays. 

<ESC>  “  Returns  the  user  to  screen  0.5. 
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RTHs  MDhDId  System) 


MODE:  W 


SYSTEM  DESCRIPTION 


1-  Mission  Areas  Aviation 

System  Types  Utility  Helicopters 
System  Names 

Mission/Cond it  ions  Set  Name  s 


Screen  0.10  - 


System  Descriptioii  menu  with  Mission  Area  and 
System  Type  selected. 
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Screen  0.11  -  List  of  SPREA  System  Names  for  the  current  System 
Type. 

From  this  screen  the  user  can  select  a  system  that  has 
undergone  a  Product  1  SPREA  analysis. 

User  Actions! 

The  user  will  use  normal  menu  selection  procedures  to  choose 
a  system  name  from  the  list.  Next  screen  is  0.12. 

<ESC>  -  Returns  the  user  to  screen  0.10. 

Input  File! 

Product  1  System  files  for  the  current  System  Type. 
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s  MDP>  I d  Byst  ern> 


MODEii  Work 


SYSTEM  DESCR I PT I ON 


i -  Mission  Pr  0  a :  P v i a  t i on 
E.  System  Type:  Utility  Helicopters 

3.  System  Name: 

4.  Mission/Cond i t ions  Set  Name: 


SPREP  UTILITY  HELICOPTERS 

1. 

UH-l  Iroquois 

d.  m 

UH-60  Black  Hawk 

UH~£C 

4. 

CJ 

S « 
7. 

a- 

s. 

0, 

MORE  I 

Screen  0.11  - 


List  of  SPREA  System  Names  for  the  current  System 
Type. 
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Screen  0.12  -  System  Description  Menu  with  Mission  Area,  System 
Type,  and  System  Name  identified. 

From  this  menu,  the  user  can  select  the  Mission/Condition 

Set  Name  field  or  any  of  the  previously  selected  fields. 

User  Actions; 

1.  Mission  Area.  Next  screen  is  0.7. 

2.  System  Type.  Next  screen  is  0.9. 

3.  System  Name.  If  the  user  has  previously  chosen  to 

select  a  system  from  a  Product  1  SPREA  analysis,  the 
next  screen  will  be  0.11.  If  the  user  chose  to 
identify  a  new  system  entirely  from  scratch,  the  next 
screen  will  be  0.22. 

4.  Mission/Condition  Set  Name.  If  the  user  has  previously 

chosen  to  select  a  system  from  a  Product  1  SPREA 

analysis,  the  next  screen  will  be  0.13.  If  the  user 

chose  to  identify  a  new  system  entirely  from  scratch, 
the  next  screen  will  be  0.24. 

<ESC>  Returns  the  user  to  screen  0.5. 
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MDft>  Id  System) 


MODE:  Work 


! 

SYSTEM  DESCRIPTION  j 

1. 

Missio 

n  Prea :  Pv i at i on 

C!  n 

System 

Type:  Utility  Helicopters 

%:!j  m 

System 

Name:  UH~-60  Etlack  Hawk 

4. 

Missio 

n/ Cond i t i ons  Set  Name : 

Screen  0.12  •  System  Description  Menu  with  Mission  Area,  System 
Type,  and  System  Name  identified. 
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Screen  0.13  -  SPREA  Mission/Condition  Set  file  names  for  the 
current  System  Name. 

From  this  screen,  the  user  can  select  a  Mission/Condition 

Set  file  that  was  developed  for  the  SPREA  analysis,  or  view 

the  contents  of  a  SPREA  Mission/Condition  Set  file. 

User  Actions! 

select  When  the  select  command  is  highlighted  the  user 

can  use  normal  menu  selection  procedures  to  choose 
one  of  the  listed  files  as  the  Mission/Condition 
Set  file  for  the  Product  5  MDA  analysis.  Next 
screen, is  0.21. 

view  When  the  view  command  is  highlighted,  the  user  can 

use  normal  menu  selection  procedures  to  view  the 
contents  of  one  of  the  listed  files.  Next  screen 
is  0.14. 

<ESC>  Returns  the  user  to  screen  0.12. 

Input  Files; 

SPREA  Conditions  by  System  Types  file  names. 


-'ATH:  MDP>  Id  System 


MODES  Work 


1- 


4. 


SYSTEM  DESCR I PT I ON 


Mission  Prea :  Pviation 
System  Type:  Utility  Helicopters 
System  Name:  UH—60  Black  Hawk 
Mission/Cond i t ions  Set  Name: 


SPREH  MISSION/CGMDITION  SETS 
FOR:  UH-60  BLACK  HAWK 

1.  USNORMAL 

£.  USAl 

3-  EUROPE! 

4.  EUROPEE 

5.  MIDEASTl 

select 

V  i  ew 

Screen  0.13  -  SPREA  Misslon/Gonditlon  Set  file  names  for  the 
current  System  Name. 


3-49 


Screen  0.14  -  SPREA  Mission/Condition  Set  file  menu. 

From  this  screen,  the  user  can  choose  to  view  typical  or 
additional  conditions  for  the  system  and  mission  identified 
in  the  SPREA  analysis. 

User  Actions; 

1.  Typical  Conditions.  Next  Screen  is  0.15. 

2.  Additional  Conditions.  If  Additional  Conditions  have 
been  defined  for  the  current  system,  the  next  Screen  is 
0.17.  If  no  Additional  Conditions  have  been  defined 
for  the  current  system,  the  next  screen  is  0.19. 

<ESC>  Returns  the  user  to  screen  0.13. 

Input  File; 

Selected  SPREA  Conditions  by  System  Type  file. 
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PATH  2  >  :i:  d  Sy St  ern 


MODES  Work 


SPRER  MISSION/GDMDITIGN  SET 


File  name ;  U3P 1 

System  Types  Utility  Helicopter 
System  Name;  UH-60  E«lack  Hawk 
Mission;  Transport  Combat  Troops 


1«  Typical  Conditions 
2.  Additional  Conditions 


Screen  0.14  - 


SPREA  Mission/Condition  Set  file  menu. 


3-51 


Screen  0.15  -  Typical  Conditions  menu  for  the  selected 
Mission/Conditions  Set  file. 

From  this  screen  the  user  can  select  a  category  of  typical 
conditions  to  view. 

User  Actions: 

The  user  will  use  normal  menu  selection  procedures  to  select 
a  typical  conditions  category  from  the  list.  The  next 
screen  is  an  example  of  the  typical  environmental  conditions 
0.16. 


<ESC>  Returns  the  user  to  screen  0.14. 


Input  File; 

Selected  SPREA  Conditions  by  System  Type  file. 
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PATH:  MDtt>Id  System 


MGDEs  Work 


("*■ 

BP  REP) 

M ;[  SS I  ON  /  COMD I T  I  ON  SET 

i  File  name;  USAl 

Sysbern 

Typ®2  Utility  Helicoptev' 

System 

Name:  UH-60  Black  Hawk 

Mission 

s  Transpov't  Combat  Troops 

i  TYPICAL  CONDITIONS 

L 

1. 

En V i ronment  a 1 

C.  m 

Terrain 

m 

Target /Threat  Related 

4- 

L- 

Friendly  F'crce  Related 

Screen  0.15  - 


Typical  Conditions  menu  for  the  selected 
Mission/Conditions  Set  file. 


Screen  0.16  -  Typical  Conditions  screen  for  the  selected 
category . 

From  this  screen  the  user  can  view  the  parameters  for  the 
selected  typical  conditions  category. 

User  Actions: 

The  only  acceptable  user  action  from  this  screen  is  the 
<ESC>  key  to  return  to  the  previous  menu.  The  next  screen 
is  0.15. 

Input  File; 

Selected  SPREA  Conditions  by  System  Type  file. 


3-54 


SPREft  MISSrON/CONDITION  SET 


File  name:  USftl 

System  Type:  Utility  Helicopter 
System  Name:  UH-SO  Black  Hawk 
Mission:  Transport  Combat  Troops 


TYPICAL  ENVIRONMENTAL  CONDITIONS 


Day/Night:  night 

Visibility  Type:  clear 
Flight  Rules/Conditions:  VFR/VFC 
Climate  Type:  Basic/High  Humid 
Altitude:  5000  ft- 

Electromagnet ic  Hazards :  without 


0.16 


Typical  Conditions  Screen  for  the  Selected 
Category 


Screen  0.17 


Additional  Conditions  Menu.  From  this  menu,  the 
user  can  select  an  additional  conditions  category 
to  view. 


User  Actions; 

The  user  will  use  normal  menu  selection  procedures  to  select 
an  Additional  Conditions  category  from  the  list.  The  next 
screen  is  an  example  of  the  additional  environmental 
conditions  screen  0.18. 

Pressing  the  <ESC>  key  will  return  the  user  to  screen  0.15. 
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mTHs  MDn>:i:d  System 


MODE  2  W 


i  SPREA 

I  _ 

N I SS I ON / CGND I T I ON  SET 

F“ile  riarne :  UGfiJ. 

System 

Type:  Utility  Helicopter  j 

System 

Names  UH--60  Black  Havvik  j 

M i ss i on 

s  Transport  Combat  Troops  j 

_  _  _ 

ADDITIONAL  CONDITIONS  j 

1. 

Env  i  ronrnent  a  1 

iZ!  m 

Terrain 

^  m 

Target /Threat  Related 

4. 

F r i end  1 y  Force  Re 1 a t  ed 

Screen  0.17  • 


Additional  Conditions  Menu.  From  this  menu,  the 

user  can  select  an  cdditlonal  conditions  category 
to  view. 
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Screen  0.18  -  Additional  Conditions  screen  for  the  selected 
category. 

From  this  screen  the  user  can  view  the  parameters  for  the 
selected  additional  conditions  category. 

User  Actions; 

The  only  acceptable  user  action  from  this  screen  is  the 
<ESC>  key  to  return  to  the  previous  menu.  The  next  screen 
is  0.17. 

Input  File; 

Selected  SPREA  Conditions  by  System  Type  file. 
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:‘ATH2  MDm>  Id  System 


MODE:  Work 


SPREA  MIS3IGN/CDNDITI0W  SET 


File  name:  USPl 

System  Type:  Utility  Helicopter 
System  Name:  UH-SO  E«lack  Hawk 
Mission:  Transport  Combat  Troops 


HDDITIONHL  ENV I RONMENTHL  CONDITIONS 


Spec  i  a  1  Env  i  ronrnent  s  :  Mount  a  i  n 

Wind  Direction  Type:  Headwind 

Wind  Di  v'ect  ion-Measured  (degrees):  0 

Wind  Velocity  (knots):  30 

Pressure  ( rn  i  1 1  i  bars )  :  1 0 1 3 

T  em  per  a  t  ur  e ( d  e  g  r e  es )  :  40 

P‘r ec  i  p  i  t  a  I;  i  o n  :  R a  i  n 

V i s i b i 1 i t  y  ( met  ers )  :  1 500 


Screen  0.18 


Additional  Conditions  screen  for  the  selected 
category. 
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Screen  0.19 


No  Additional  Conditions  message. 


Displays  when  the  user  has  selected  to  view  Additional 
Conditions  from  a  Mission/Condition  Set  SPREA  file  and  none 
have  been  defined. 

User  Actions; 

The  only  accepted  user  actions  are  pressing  the  <ENTER>  or 
<ESC>  keys.  Either  action  will  return  the  user  to  screen 
0.14. 
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PATH  s  MDA >  I  d  Sy St  ern 


MODE 


SPREA  MISSIGN/CGNDmON  BET 


File  name :  USA i 

System  Type:  Utility  Helicopter 
System  Name:  UH-60  E-ilack  Hawk 
Mission:  Transport  Combat  Troops 


No  Additional  Conditions  have  been 
specified  for  this  system 

Press  <ENTER>  to  Continue 


Screen  0.19  - 


No  Additional  Conditions  message 


Screen  0.21  -  System  Description  screen  with  Mission  Area, 

System  Type,  System  Name,  and  Mission/Condition 
Set  Name  identified. 

From  this  screen,  the  user  can  modify  any  of  the  fields  or 
return  to  the  Identify  System  menu. 


User  Actions; 

1.  Mission  Area  -  Next  screen  is  0.7. 

2.  System  Type  -  Next  screen  is  0.9. 

3.  System  Name  -  If  the  user  has  previously  chosen  to 
select  a  system  from  a  Product  1  SPREA  analysis,  the 
next  screen  is  0.11.  If  the  chose  to  identify  a  new 
system  entirely  from  scratch,  the  next  screen  is  0.22. 

4.  Mission/Condition  Set  Name  -  If  the  user  has  previously 
chosen  to  select  a  system  from  a  Product  1  SPREA 
analysis,  the  next  screen  is  0.13.  If  the  user  chose 
to  identify  a  new  system  entirely  from  scratch,  the 
next  screen  is  0.24. 

<ESC>  Returns  the  user  to  the  Identify  System  menu,  0.5. 
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t'ftTH:  MD«>Id  System) 


MODE:  Work 


■"  - . .  ^ 

j  SYSTEM  DESCRIPTION  j 

1. 

M i ss i o 

n  ftrea :  ft v i at i on 

iz! « 

System 

JypBi  Utility  Helicopters 

3. 

System 

Name:  UH-60  Black  Hawk 

4- 

M  i  <ss  i  o 

n/Cond i t ions  Set  Name:  USftl 

Screen  0.2 1  - 


System  Description  screen  with  Mission  Area, 
System  Type,  System  Name,  and  Mission/Condition 
Sot  Name  identified. 
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Screen  0.22  -  System  Description  menu  with  a  flashing  cursor 
displayed  in  the  System  Name  field. 

From  this  screen,  the  user  can  enter  a  system  name  for  the 
current  evaluation  from  the  keyboard. 

User  Actions! 

The  system  will  wait  for  a  string  of  allowable  characters  to 
be  entered  as  the  system  name.  The  user  will  terminate  the 
string  by  pressing  the  <ENTER>  key.  The  system  name  must 
begin  with  an  alpha  character  and  can  contain  alpha, 
numeric,  underscore,  hyphen,  and  space  characters. 

Characters  in  the  System  Name  will  be  converted  into  a  DOS 
file  name  via  a  collapsing  algorithm  (see  below) .  If  the 
System  Name  contains  any  characters  that  are  not  allowed,  a 
tone  will  sound  and  an  error  message  will  display  prompting 
the  user  with  the  rules  for  System  Names.  Next  screen  is 
0.23. 

<ESC>  Returns  the  user  to  screen  0.10. 

Algorithms ; 

The  following  algorithm  will  be  used  to  collapse  the  System 
Name  into  a  DOS  file  name: 

o  remove  all  space  characters 

o  change  everything  to  upper  case 

o  remove  all  vowels 

o  remove  characters  at  regular  and  predictable 

intervals  until  the  name  conforms  to  DOS  file  name 
rules 

If  the  file  name  that  results  from  the  collapse  algorithm 
matches  an  existing  file  name,  a  message  will  be  displayed 
prompting  the  user  to  change  the  System  Name  slightly. 
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MODE :  W 


-'PITH 


MDP> Id  System) 


b YBTEjvl  DESC R 1 PT I  ON 

1. 

M i ss i on  Area :  Pv i at i on 

c!  ■ 

System  Type:  Utility  Helicopters 

3. 

System  Names  — . 

4, 

M i ss i on/Cond i t i ons  Set  Name  s 

Screen  0.22  - 


System  Description  Tienu  with  a  flashing  cursor 
displayed  in  the  System  Name  field. 
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Screen  0.23  -  System  Description  menu  with  Mission  Area,  System 
Type,  and  System  Name  identified. 

From  this  screen,  the  user  can  select  the  Mission/Condition 
Set  Name  field  or  any  of  the  previously  identified  fields. 

User  Actions: 

1.  Mission  Area  -  Next  screen  is  0.7. 

2.  System  Type  -  Next  screen  is  0.9. 

3.  System  Name  -  Next  screen  is  0.22. 

4.  Mission/Condition  Set  Name  -  Next  screen  is  0.24. 

<ESC>  Returns  the  user  to  screen  0.5. 
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MODE:  Work 


MDft> id  System) 


SYSTEM  DESCRIPTION 


1.  Mission  Prea :  Pviation 
£.  System  Type:  Utility  Helicopters 
3-  System  Name:  UH-SO  Black  Hawk 
4.  Mission/Cond i t ions  Set  Name: 


Screen  0.23  - 


System  Description  menu  with  Mission  Area,  System 
Type,  and  System  Name  identified. 
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Screen  0.24 


List  of  Current  Mission/Condition  Set  files  for 
the  identified  System  Name. 


From  this  screen,  the  user  can  use  normal  (generic)  menu 
selection  strategies  to  select,  insert,  modify,  copy,  or 
delete  a  Mission/Condition  Set  file  (see  section  3.3). 


User  Actions! 

select  When  the  select  command  is  highlighted,  the  user 
can  use  normal  selection  procedures  to  choose  one 
of  the  listed  files  as  the  Mission/Condition  Set 
file  for  this  analysis.  Next  screen  is  0.21. 


insert  When  the  insert  command  is  highlighted,  the  user 
can  use  normal  strategies  to  choose  the  file  name 
after  which  a  new  file  name  will  be  inserted. 

Next  screen  is  0.25. 


modify 


When  the  modify  command  is  highlighted,  the  user 
can  use  normal  strategies  to  choose  a  file  name 
for  which  the  user  wants  to  modify  current 
mission/condition  parameters.  Next  screen  0.30. 


copy  When  the  copy  command  is  highlighted,  the  user  can 

use  normal  scrategies  to  choose  a  file  name  to 
copy.  Next  screen  is  0.40. 

delete  When  the  delete  command  is  highlighted,  the  user 

can  use  normal  strategies  to  choose  a  file  name  to 
delete  from  the  disk  storage.  Next  screen  is 
0.42. 


<ESC>  Returns  the  user  to  screen  0.23. 


3-68 


Input  Files: 

Mission/Condition  Set  files  that  have  been  developed  for  the 
current  system  name. 
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c-j 


Screen  0.24  - 


List  of  Current  Mission/Condition  Set  files  for 
the  identified  System  Name. 
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Screen  0.25  -  List  of  Mission/Condition  Set  files  for  the 
current  system  name  with  a  flashing  cursor 
indicating  an  insertion  point  for  a  new  file  name. 

From  this  screen,  the  user  can  enter  a  new  Mission/Condition 
Set  file  name. 

User  Actions! 

The  system  will  wait  for  a  string  of  allowable  characters  to 
be  entered  as  the  new  Mission/Condition  Set  file  name.  The 
user  will  terminate  the  string  by  pressing  the  <ENTER>  key. 
The  file  name  must  begin  with  an  alpha  character  and  can 
contain  up  to  eight  alpha,  numeric,  underscore,  and  hyphen 
characters.  All  characters  beyond  the  first  eight  will  be 
truncated.  If  the  Mission/Condition  Set  file  name  contains 
any  characters  that  are  not  allowed,  a  tone  will  sound  and 
an  error  message  will  display  prompting  the  user  with  the 
rules  for  Mission/Condition  Set  names.  Next  screen  is  0.26. 

<ESC>  Returns  the  user  to  screen  0.24. 
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OJ  fO 


SETS  FOR:  UH-60  BL«CK  HAWK 

1-  Mission  Areas  Aviation  - 

System  Types  Utility  Helicopters 

System  Names  UH—60  Black  Hawk  1-  USAl 

Mission/Condit ions  Set  Names  £.  — 

3.  USNORMAL 

- - ^ —  4.  MIDEAST 


Screen  0.25  -  List  of  Mission/Condition  Set  files  for  the 

current  system  name  with  a  flashing  cursor 
indicating  an  Insertion  point  for  a  new  file  name. 
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Screen  0.26  -  Mission/ Condition  Set  Definition  menu. 

From  this  screen,  the  user  can  choose  to  identify  the 
Mission,  the  typical  conditions,  and/or  the  additional 
conditions  for  this  evaluation. 

User  Actions; 

1.  Mission  -  Next  screen  is  0.27. 

2.  Typical  Conditions  -  Next  screen  is  0.31. 

3.  Additional  Conditions  -  Next  screen  is  0.36. 

<ESC>  Returns  the  user  to  screen  0.32. 
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fcTlTHs  MDf-l)  Id  System 


MODE:  Work 


M  X  33 1 GW / COND I T  X  ON  SET  DEF I N I T  X  0 W 


Names  US PI 

System  Types  Utility  Helicopter 
System  Names  UH-60  Black  Hawk 


1 -  Mi ss i on : 

E.  Typical  Conditions 
3 .  Add i t i ona 1  Cond i t i ons 


Screen  0.26 


Mission/Condition  Set  Definition  menu. 
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Screen  0.27 


Mission/Condition  Set  Definition  menu  with 
"select”  and  "type-in"  commands  displayed. 

From  this  screen,  the  user  can  choose  to  type  in  a  mission 
name  or  select  one  from  a  list  of  missions  for  the  current 
System  Type. 

User  Actions; 

select  Next  screen  is  0.28. 
type-in  Next  screen  is  0.29. 

<ESC>  Returns  the  user  to  screen  0.26. 
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JPITH;  MDfi>  Id  System 


MODE:  Work 


r 

1  M I  S3 1  f3N  /  COMD :[  T I  ON  SET  DEF I N I T  .1  ON 

1 ..  _  .  „ .  _  _ 

Name:  USftl 

System  Type: 

Utility  Hel i copter 

System  Name: 

UH-60  Black  Hawk 

1.  Mission: 

1  E.  Typical  Conditions 

3.  Add i t i ona 1  Co 

nd i t i ons 

select 

type-in 

Screen  0.27  Mission/Condition  Sn  Definition  Menu 
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Screen  0.28 


List  of  missions  for  the  identified  System  Type. 


From  this  screen,  the  user  can  select  a  mission  for  this 
evaluation . 

User  Actions! 

The  user  will  use  normal  selection  procedures  to  choose  a 
mission  name  from  the  displayed  list.  Next  screen  is  0.30. 

<ESC>  Returns  the  user  to  screen  0.27. 

Input  File: 

Product  5  Missions  by  System  Type  Taxonomy  file. 
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w  n j 


MDft> Id  System 


MO 


1 

MISSIDN/CONDITION  SET  DEFINITION  j 

Name;  USftl 
System  Type: 
System  Name: 

Utility  Helicopter  Missions 

1.  Transport  Combat  Troops 

2.  Transport  Logistical  Supplies 

3.  Evacuate  Casualties 

4. 

1.  Missiori: 

Typical  Condi 
3 .  Add i t i ona 1  Co 

j  select 

I _ 


Screen  0.28  - 


List  of  missions  for  the  identified  System  Type. 


Screen  0.29  -  Mission/Condition  Set  Definition  menu  with  a 

flashing  cursor  displayed  in  the  mission  field. 

From  this  screen,  the  user  can  enter  a  mission  name  for  this 
evaluation. 

User  Actions! 

The  user  will  enter  a  string  of  characters  to  describe  the 
current  mission.  The  string  will  be  terminated  by  pressing 
the  <ENTER>  key.  The  next  screen  is  0.30. 

<ESC>  Returns  the  user  to  screen  0.27. 
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JftTH:  MDft> Id  System 


MODE:  Work 


1  MIS3IDN/C0NDITI0N  SET  DEFINITION 

i  _  _  _  _  _  _  ......  .  _ 

Name:  USRl 

1  System  Type: 

Utility  Helicopter 

1  System  Name: 

UH-60  Black  Hawk 

!  1-  Mission:  ^ 

1  E.  Typical  Conditions 

3.  Additional  C 

imd  i  t  i  ons 

select 

type-in 

Screen  0.29  - 


Mission/Condition  Set  Definition  menu  with  a 
hashing  cursor  dispiuyed  in  the  mission  field. 
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Screen  0.30  -  Mission/Condition  Set  Definition  menu  with  the 
mission  identified. 

From  this  screen,  the  user  can  choose  to  identify  typical 
conditions,  additional  conditions,  or  change  the  mission 
name. 

User  Actions; 

1.  Mission  -  Next  screen  is  0.27. 

2.  Typical  Conditions  -  Next  screen  is  0.31. 

3.  Additional  Conditions  -  Next  screen  is  0.36. 

<ESC>  Next  screen  0.32. 
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’'fiTHi  Id  System 


MODES  Work 


MISSION/CONDITIGN  SET  DEFINITION 


Name:  USPl 

System  Type:  Utility  Helicopter 
System  Name:  UH-SO  Black  Hawk 


Mission:  Transport  Combat  Troops 
Typical  Cond i t i ons 
Ad d i t i ona i  Cond i t i ons 


Screen  0.30  - 


Mission/Condition  Set  Definition  menu  with  the 
mission  identified. 
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Screen  0.31  -  Mission/Condition  Set  Definition  -  Typical 
Conditions  menu. 

From  this  screen,  the  user  can  select  a  category  of  typical 
conditions  to  view/modify. 

User  Actions; 

The  user  can  use  normal  menu  selection  procedures  to  choose 
a  category  of  typical  conditions.  The  next  screen  (0.32)  is 
an  example  of  the  Typical  Environmental  Conditions  screen. 
The  screens  from  the  other  category  selections  present  the 
conditions  for  each  category  in  the  same  format.  The 
screens  for  each  Typical  Conditions  category  have  default 
conditions  highlighted. 

<ESC>  Returns  the  user  to  screen  0.30. 

-Input  Files; 

The  Product  5  Conditions  by  System  Type  Taxonomy.  See 
Section  4. 


:'ATH;  MDft)  Id  System 


MODE!  W 


MISSION /CONDITION  SET  DEFINITION 

Name : 

USftl 

System 

Type:  Utility  Helicopter 

System 

Name:  UH-60  Black  Hawk 

TYPICfiL  CONDITIONS 

r 

1. 

Env i ronment  a 1 

Cm  m 

Terrain 

m 

Target /Threat  Related 

4. 

Friendly  Force  Related 

Screen  0.31  - 


Mlsslon/Conditlon  Set  Definition  -  Typical 
Conditions  menu. 
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Screen  0.32  -  Mission/Condition  Set  Definition  -  Typical 
Environmental  Conditions  menu. 

From  this  screen,  the  user  can  select  environmental 
categories  to  modify  conditions  for  each  category. 

User  Actions; 

Using  normal  menu  selection  procedures,  the  user  will  select 
a  category  for  which  he  or  she  wants  to  change  the 
conditions  parameter.  If  the  parameter  for  the  selected 
field  is  one  that  can  be  selected  from  the  conditions 
taxonomy,  the  user  is  presented  with  a  list  of  the  possible 
choices.  The  next  screen  (0.33)  is  an  example  of  the 
condition  parameters  screen  for  the  ’’Visibility  Type” 
category.  The  screens  from  the  other  category  selections 
present  parameters  for  each  category  in  the  same  format. 

The  screens  for  each  category  have  default  or  current 
conditions  highlighted. 

If  the  user  selects  a  field  from  the  Typical  Environmental 
Conditions  menu  that  must  be  input  by  the  user,  a  flashing 
cursor  will  be  displayed  in  that  field.  Screen  0.34  is  an 
example  of  this  kind  of  input. 

<ESC>  Returns  the  user  to  screen  0.31. 

Input  Files; 

Product  5  Conditions  by  System  Type  Taxonomy. 
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ATH  s  MDh  >  I  d  3y st  ern 


t^IGDE:  W 


Screen  0.32  -  Mission/Condition  Set  Definition  -  Typical 
Environmental  Conditions  menu. 


Screen  0.33  -  Visibility  Type  menu. 


This  is  an  example  of  how  the  parameters  for  each 
environmental  conditions  category  is  displayed.  From  this 
screen,  the  user  can  choose  a  category  parameter. 

User  Actions; 

The  user  can  use  normal  procedures  to  select  a  parameter 
from  the  list.  Next  screen  is  0.32.  If  the  user  selects 
the  "other”  option  (which  appears  on  all  parameter  category 
menus)  he  or  she  can  type  in  a  new  condition  parameter. 

Next  screen  0.35. 

<ESC>  Returns  the  user  to  0.32. 

Input  Files; 

Product  5  Conditions  by  System  Type  Taxonomy. 
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Screen  0.33  - 


Visibility  Type  menu. 


Screen  0.34 


Mission/Condition  Set  Definition  -  Typical 
Environmental  Conditions  menu  with  a  flashing 
cursor  in  the  "Altitude:"  field. 

From  this  screen,  the  user  can  enter  a  value  representing 
the  expected  altitude  in  which  the  system  under  evaluation 
must  perform  to  accomplish  the  mission. 

User  Actions: 

For  each  field  that  requires  user  input  to  establish  the 
condition  parameter,  the  system  will  wait  for  the 
appropriate  input.  For  example,  in  this  case,  the  system 
will  wait  for  numeric  characters  that  represent  the  number 
of  feet  of  altitude.  The  user  will  terminate  the  input  by 
pressing  the  <ENTER>  key.  If  the  input  is  not  the 
appropriate  character  type  (alpha  or  numeric)  the  system 
will  display  an  error  message.  Next  screen  is  0.32. 

<ESC>  Returns  the  User  to  screen  0.32  and  replaces  the 
previous  value. 


PATH:  MDA>Id  System 


MODE:  Work 


MISSION/CONDITION  SET  DEFINITION 


Name:  USAl 

System  Type:  Utility  Helicopter 
System  Name:  UH--60  Black  Hawk 


TYPICAL  ENVIRONMENTAL  CONDITIONS 


1.  Day/Night:  right 

E.  Visibility  Type:  smog 

3,  Flight  Rules/Cond i t ions :  VFR/VFC 

4-  Climate  Type:  Basic/High  Hamid 

5.  Altitude:  — 

6-  Electromagnetic  Hazards:  without 


Screen  0.34  - 


Mission/Condition  Set  Definition  -  Typicai 
Environmental  Conditions  menu  with  a  flashing 
cursor  in  the  "Altitude:"  field. 
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Screen  0.35  -  Visibility  Type  menu  with  a  flashing  cursor 
displayed  in  a  blank  parameter  field. 

From  this  screen,  the  user  can  enter  a  condition  parameter 
not  shown  as  a  menu  option. 

User  Actions; 

The  user  will  use  the  normal  editing  keys  to  enter  a  string 
of  characters  that  will  be  used  as  the  new  condition 
parameter.  Pressing  the  <ENTER>  key  will  terminate  the 
input.  Next  screen  0.32. 

<ESC>  Returns  the  user  to  screen  0.32. 
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ftTH:  MDA> Id  System 


MODE:  Work 


MISSION/CONDITION  SET  DEFINITION 

Name:  USAl 

System  Type:  Utility  Helicopter 

System  Name:  UH-60  Black  Hawk 

TYPICAL  ENVIRONMENTAL  CONDITIONS 

1.  Day/Night:  night 

2.  Visibility  Type:  clear 

3-  Flight  Rules/Cond i t ions :  VF 

4-  Climate  Type:  Basic/High  Hui 

Altitude:  5000  ft. 

6.  Elect rornagnet  ic  Hasar.ds:  wi 

VISIBILITY  TYPE 

1.  clear 

2.  fog 

3.  hase- 

•  4.  smoke 

5.  ~ 

Screen  0.35  - 


Visibility  Type  menu  with  a  flashing  cursor 
displayed  in  a  blank  parameter  field. 


Screen  0.36  -  Mission/Condition  Set  Definition  -  Additional 
Conditions  menu. 

From  this  screen,  the  user  can  select  a  category  of 
additional  conditions  to  view/modify. 

User  Actions: 

The  user  can  use  normal  menu  selection  procedures  to  choose 
a  category  of  additional  conditions.  The  next  screen  (0.37) 
is  an  example  of  the  Additional  Environmental  Conditions 
screen.  The  screens  from  the  other  category  selections 
present  the  conditions  for  each  category  in  the  same  format. 
The  screens  for  each  Additional  Conditions  category  have 
default  conditions  highlighted. 

<ESC>  Returns  the  user  to  screen  0.30. 

Input  Files: 

The  Product  5  Conditions  by  System  Type  Taxonomy.  See 
Section  4. 
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PftTH:  MDft> Id  System 


MODE:  Work 


MISSION/CONDITION  SET  DEFINITION 


Name:  USftl 

System  Type:  Utility  Helicopter 
System  Name:  UH-60  Black  Hawk 


ADDITIONAL  CONDITIONS 


1  -  Env  i  r  onrnent  a  1 
Terrain 

3-  Target /Threat  Related 
4.  Friendly  Force  Related 


Screen  0.36  - 


Mission/Condition  Set  Definition  -  Additional 
Conditions  menu. 
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Screen  0.37  -  Mission/Condition  Set  Definition  -  Additional 
Environmental  Conditions  menu. 

From  this  screen,  the  user  can  select  environmental 
categories  to  modify  conditions  for  each  category. 

User  Actions; 

Using  normal  menu  selection  procedures,  the  user  will  select 
a  category  for  which  he  or  she  wants  to  change  the 
conditions  parameter.  If  the  parameter  for  the  selected 
field  is  one  that  can  be  selected  from  the  conditions 
taxonomy,  the  user  is  presented  with  a  list  of  the  possible 
choices.  The  next  screen  (0.38)  is  an  example  of  the 
condition  parameters  screen  for  the  "Wind  Direction  Type" 
category.  The  screens  from  the  other  category  selections 
present  parameters  for  each  category  in  the  same  format. 

The  screens  for  each  category  have  default  or  current 
conditions  highlighted. 

If  the  user  selects  a  field  from  the  Additional 
Environmental  Conditions  menu  that  must  be  input  by  the 
user,  such  as  the  temperature  or  wind  velocity,  a  flashing 
cursor  will  be  displayed  in  that  field.  Screen  0.39  is  an 
example  of  this  kind  of  input. 

<ESC>  Returns  the  user  to  screen  0.36. 

Input  Files; 

Product  5  Conditions  by  System  Type  Taxonomy. 
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PATH:  MDP> Id  System 


MODE:  Work 


MISSION/CONDITION  SET  DEFINITION 


Name:  USPl 

System  Type:  Utility  Helicopter 
System  Name:  UH-60  Black  Hawk 


ADDITIONAL  ENVI RONMENTAL  CONDITIONS 


S pec i a 1  En v i r onmen t  s :  Mount  a i n 
Wind  Direction  Type:  Headwind 
Wind  Direct i on— Measured  (degrees):  O 
Wind  Velocity  (knots):  30 
Pressure  ( m i 1 1 i bars ) :  1013 

Ternperat  ure  (degrees)  :  40 
Precipitation:  Rain 
Visibility  (meters):  1500 


Screen  0.37  - 


Mission/Condition  Set  Definition  -  Additional 
Environmental  Conditions  menu. 
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Screen  0.38 


Wind  Direction  Type  menu. 


This  is  an  example  of  how  the  parameters  for  each 
environmental  conditions  category  is  displayed.  From  this 
screen,  the  user  can  choose  a  category  parameter. 

User  Actions: 

The  user  can  use  normal  procedures  to  select  a  parameter 
from  the  list.  Next  screen  is  0.37.  If  the  user  selects 
the  "other”  option  (which  appears  on  all  parameter  category 
menus)  he  or  she  can  type  in  a  new  condition  parameter. 

Next  screen  0.39. 

<ESC>  Returns  the  user  to  0.37. 

Input  Files; 

Product  5  Conditions  by  System  Type  Taxonomy. 
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MISSION/CQNDITION  SET  DEFINITION 


Name:  USAl 

System  Type:  Utility  Helicopter 
System  Name:  UH-60  Black  Hawk 


HDDITIONPL  ENVIRONMENTAL  CONDITIONS 


Special  Envi rorirnerit s  :  Mountain 
Wind  Direction  Type:  Headwind 
Wind  Direct ion-Measured  (degrees) 
Wind  Velocity  (knots) :  30 
Pressure  (millibars):  1013 
Temperat  Lire  (degrees)  :  40 
Precipitation:  Rain 
Visibility  (meters):  1500 


O 


WINE 

DIRECTION  TYPE 

1. 

Headwind 

iZ.  a 

Tailwind 

3. 

Cross  wind 

4a 

No  wind 

5a 

Other 

Screen  0.38  - 


Wind  Direction  Type  menu. 


Screen  0.39  -  Wind  Direction  Type  menu  with  a  flashing  cursor 
displayed  in  a  blank  parameter  field. 

From  this  screen,  the  user  can  enter  a  condition  parameter 
not  shown  as  a  menu  option. 

User  Actions; 

The  user  will  use  the  normal  editing  keys  to  enter  a  string 
of  characters  that  will  be  used  as  the  new  condition 
parameter.  Pressing  the  <ENTER>  key  will  terminate  the 
input.  Next  screen  0.37. 

<ESC>  Returns  the  user  to  screen  0.37. 
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PATH:  MDA>Id  System 


MODE:  Work 


MISSION/CONDITION  SET  DEFINITION 


Name:  USAl 

System  Type:  Utility  Helicopter 
System  Name:  UH-60  Black  Hawk 


ADDITIONAL  ENVIRONMENTAL  CONDITIONS 


Special  Environment s :  Mountain 
Wind  Direction  Type:  Headwind 
Wind  Direct ion—Measured  (degrees):  0 
Wind  Velocity  (knots):  30 
Pressure  (millibars):  1013 
Temperature (degrees) :  40 
Precipitation:  Rain  • 

Visibility  (meters):  1500 


WIND  DIRECTION  TYPE 

1- 

Headwind 

£. 

Tailwind 

3. 

Cross  wind 

4. 

No  wind 

5. 

— 

Screen  0.39  -  Wind  Direction  Type  menu  with  a  flashing  cursor 
displayed  in  a  blank  parameter  field. 
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Screen  0.40  -  List  of  Mission/Condition  Set  files  for  the 

current  System  Name  with  a  flashing  cursor  in  the 
space  below  the  file  to  be  copied. 

From  this  screen,  the  user  can  enter  a  new  name  for  the 
copied  file. 

User  Actions! 

The  system  will  wait  for  a  string  of  allowable  characters  to 
be  entered  as  the  copied  Mission/Condition  Set  file  name. 

The  user  will  terminate  the  string  by  pressing  the  <ENTER> 
key.  The  file  name  must  begin  with  an  alpha  character  and 
can  contain  up  to  eight  alpha,  numeric,  underscore,  and 
hyphen  characters.  All  characters  beyond  the  first  eight 
will  be  truncated.  If  the  Mission/Condition  Set  file  name 
contains  any  characters  that  are  not  allowed,  a  tone  will 
sound  and  an  error  message  will  display  prompting  the  user 
with  the  rules  for  naming  Mission/Condition  set  files.  Next 
screen  is  0.41. 

<ESC>  Returns  the  user  to  screen  0.23. 

Input  Files; 

Product  5  Mission/ Condition  Set  files. 


3-101 


PftTH:  MDft>Id  System) 


MODE:  Work 


SYSTEM  DESCRIPTION 


1«  Mission  Prea:  Aviation 
elm  System  Type:  Utility  Helicopters 
3-  System  Name:  UH--60  Black  Hawk 
4.  Mission/Conditions  Set  Name: 


1 


CURRENT  MISSION/CONDITION  SETS 
SETS  FOR:  UH-60  BLACK  HAWK 

1. 

USAl 

USNORMAL 

4. 

MIDEftST 

select 

insert  modify  copy  delete 

Screen  0.40  -  List  of  Mission/Condition  Set  files  for  the 

current  System  Name  with  a  flashing  cursor  in  the 
space  below  the  file  to  be  copied. 
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Screen  0.41  -  List  of  Mission/Condition  Set  files  with  the 

copied  file  name  inserted  after  the  source  file. 

From  this  screen,  the  user  can  use  normal  selection 
procedures  to  initiate  any  of  the  available  commands. 

User  Actions I 

See  the  description  of  user  actions  for  screen  0.24. 
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PftTH:  MDA>Id  System) 


MODE:  Work 


SYSTEM  DESCRIPTION 


1-  Mission  Prea:  Pviation 
£.  System  Type:  Utility  Helicopters 

3.  System  Name:  UH-SO  Black  Hawk 

4.  Mission/Condit ions  Set  Name: 


CURRENT 
SETS  EOF 

MISSION/CONDITION  SETS 
UH-60  BLACK  HAWK 

1. 

USPl 

2. 

USA2 

3. 

USNORMPL 

4. 

MIDEAST 

select 

insert  modify  copy  delete 

Screen  0.41  -  List  of  Mission/Condition  Set  files  with  the 

copied  file  name  inserted  after  the  source  file. 
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Screen  0.42  -  Message  requiring  the  user  to  confirm  the  delete 
operation. 

From  this  screen,  the  user  can  either  confirm  or  cancel  the 
delete  request . 

User  Actions: 

y  causes  the  deletion  of  the  currently  highlighted 
Mission/Condition  Set  file.  Next  screen  is  0.43. 

n  cancels  the  delete  request.  Next  screen  is  0.24. 

<ESC>  cancels  the  delete  request.  Next  screen  is  0.24. 
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OJ 


PftTH:  MDA> Id  System) 


MODE:  Work 


SYSTEM  DESCRIPTION 


1-  Mission  Area:  Aviation 

System  Type:  Utility  Helicopters 

System  Name:  UH-i - 

Mission/Conditio  OK  To  Delete 

-  Y  or 


CURRENT  MISSION/CONDITION  SETS 
SETS  FOR:  UH-60  BLACK  HAWK 

File  from  Disk 

MAL 

N  ? 

ST 

select  insert 

modify  copy  delete 

Screen  0.42  -  Message  requiring  the  user  to  confirm  the  delete 
operation. 
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Screen  0.43  -  List  of  Miss ion/ Condition  Set  files  with  the 
deleted  file  removed. 

From  this  screen,  the  user  can  use  normal  selection 
procedures  to  initiate  any  of  the  available  commands. 

User  Actions; 

See  the  description  of  user  actions  for  screen  0.24. 


PftTH:  MDP> Id  System) 


MODE:  Work 


1. 

3- 

4. 


SYSTEM  DESCRIPTION 


Mission  Prea :  Pviation 
System  Type:  Utility  Helicopters 
System  Name:  UH-SO  Black  Hawk 
Mission/Cond i t ions  Set  Name: 


CURRENT  MISSION/CONDITION  SETS 
SETS  FOR:  UH-60  BLOCK  HftWK 

1.  USOl 

a-  USNORMPL 

3.  MIDEPST 

select 

: _ 

insert  modify  copy  delete 

Screen  0.43  List  of  Mission/Condition  Set  Files 
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1 


Screen  0.50  -  Resume  MDA  Analysis  menu. 

From  this  screen,  the  user  can  type-in  or  select  the  System 

Name  and  the  Mission/Condition  Set  name  for  which  to  resume 

analysis  activities. 

User  Actions; 

1.  System  name  -  When  ”type-in”  is  the  highlighted 
command,  a  flashing  cursor  will  be  displayed  in  the 
system  name  field.  Next  screen  is  0.51.  When  "select" 
is  the  highlighted  command,  the  system  will  display  a 
list  of  currently  saved  System  Names.  Next  screen  is 
0.52. 

2.  Mission/Condition  Set  name  -  When  this  field  is 
selected  and  the  user  has  not  identified  the  system 
name,  a  tone  will  sound  and  an  error  message  will  be 
displayed  indicating  that  the  system  name  must  be 
entered  first. 

<ESC>  Returns  the  user  to  screen  0.3. 

Input  Files; 

Product  5  System  Files.  Product  5  Mission/Condition  Set 

Files. 


3-109 


RESUME  MDft  ftNfiLYSIS 


1.  System  name: 

S.  Mission/Cond it  ion  Set  name: 


type— in 


select 


Screen  0.50  -  Resume  MDA  Analysis  menu. 


Screen  0.51  -  Resxame  MDA  Analysis  menu  with  flashing  cursor 
displayed  in  the  System  name  field. 

From  this  screen,  the  user  can  type-in  the  name  of  the 
system  for  which  he  or  she  wants  to  resume  the  analysis. 

User  Actions; 

The  user  will  use  normal  editing  keys  and  procedures  to 
enter  the  system  name.  Input  will  be  terminated  by  pressing 
the  <ENTER>  key.  Next  screen  0.53.  If  the  name  that  the 
user  enters  does  not  exist  on  the  current  storage  medium,  an 
error  message  indicating  such  will  display.  Next  screen 
0.50. 


<ESC>  Returns  the  user  to  screen  0.50. 

Input  Files; 

Product  5  System  Files. 
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PATH;  MDA> Id  System 


MODE:  Work 


RESUME  MDft  ANALYSIS 


1.  System  name:  — 

2.  Mission/Cond it  ion  Set  name: 


type-in 


select 


Screen  0.51  - 


Resume  MDA  Analysis  menu  with  flashing  cursor 
displayed  In  the  System  name  field. 
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Screen  0.52 


List  of  current  System  Names. 


From  this  screen,  the  user  can  select  a  system  name  for 
which  to  resTome  the  analysis. 

User  Actions: 

Using  nomal  selection  procedures,  the  user  will  choose  a 
system  name  from  the  list  for  the  analysis.  Next  screen  is 
0.53. 

<ESC>  Returns  the  user  to  screen  0.50. 

Input  Files! 

Product  5  System  Files. 
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Screen  0.53 


Resime  MDA  Analysis  with  System  Name  identified. 


From  this  screen,  the  user  can  choose  to  type-in  or  select  a 

Mission/Condition  Set  file  name  for  the  analysis  or  change 

the  System  Name. 

User  Actions; 

1.  System  name  -  When  "type-in”  is  the  highlighted 
command,  a  flashing  cursor  will  be  displayed  in  the 
system  name  field.  Next  screen  is  0.51.  When  "select" 
is  the  highlighted  command,  the  system  will  display  a 
list  of  currently  saved  System  Names.  Next  screen  is 
0.52. 

2 .  Mission/ Condition  Set  name  -  When  "type-in"  is  the 
highlighted  command,  the  system  will  display  a  flashing 
cursor  in  the  Mission/ Condition  Set  name  field.  Next 
screen  is  0.54.  When  "select"  is  the  highlighted 
command,  the  system  will  display  a  list  of  the 
currently  saved  Mission/Condition  Set  files  for  the 
identified  System  Name.  Next  screen  is  0.58. 

<ESC>  Returns  the  user  to  screen  0.3. 
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PATH:  MDft> Id  System 


MODE;  Work 


RESUME  MDA 

ANALYSIS 

1. 

System  name:  UH- 

60  Black  Hawk 

2  • 

Mission/Cond i t ion 

Set  name: 

type-in 

select 

Screen  0.53  - 


Resume  MDA  Analysis  with  System  Name  identified. 
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Screen  0.54  -  Resume  MDA  Analysis  menu  with  flashing  cursor 

displayed  in  the  Mission/Condition  Set  name  field. 

From  this  screen,  the  user  can  type-in  the  name  of  the 
Mission/Condition  Set  file  name  for  the  resiimed  analysis. 

User  Actions: 

The  user  will  use  normal  editing  keys  and  procedures  to 
enter  the  file  name.  Input  will  be  terminated  by  pressing 
the  <ENTER>  key.  Next  screen  0.56.  If  the  name  that  the 
user  enters  does  not  exist  on  the  current  storage  medivim,  an 
error  message  indicating  such  will  display.  Next  screen 
0.53.' 

<ESC>  Returns  the  user  to  screen  0.53. 
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PATH:  MDA>Id  System 


MODE:  Work 


RESUME  MDA  ANALYSIS 


1.  System  name:  UH-60  Black  Hawk 
£•  Mission/Condit ion  Set  name:  — 


type-in  select 


Screen  0.54  - 


Resume  MDA  Analysis  menu  with  flashing  cursor 
•splayed  in  the  Mission/Condition  Set  name  field. 
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Screen  0.56  -  Resume  MDA  Analysis  menu  with  the  System  and  the 
Mission/Condition  Set  names  identified. 

From  this  screen,  the  user  can  modify  either  the  System  name 

or  the  Mission/Condition  Set  name  or  return  to  the  MDA 

Flowchart  menu. 

User  Actions; 

1.  System  name  -  When  "type-in"  is  the  highlighted 
command,  a  flashing  cursor  will  be  displayed  in  the 
system  name  field.  Next  screen  is  0.51.  When  "select" 
is  the  highlighted  command,  the  system  will  display  a 
list  of  currently  saved  System  Names.  Next  screen  is 
0.52. 

2 .  Mission/Condition  Set  name  -  When  "type-in"  is  the 
highlighted  command,  the  system  will  display  a  flashing 
cursor  in  the  Mission/ Condition  Set  name  field.  Next 
screen  is  0.54.  When  "select"  is  the  highlighted 
command,  the  system  will  display  a  list  of  the 
currently  saved  Mission/Condition  Set  files  for  the 
identified  System  Name.  Next  screen  is  0.58. 

<ESC>  Returns  the  user  to  screen  0.3. 
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PATH:  MDA> Id  System 


MODE:  Work 


RESUME  MDA  ANALYSIS 


1-  System  name:  UH-60  Black  Hawk 
£.  Mission/Condit ion  Set  name;  USAl 


type-in 


select 


Screen  0.56  - 


Resume  MDA  Analysis  menu  with  the  System  and  the 
Mission/Condition  Set  names  identified. 
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Screen  0.58  -  Current  Miss ion/ Condition  Sets  for  the  identified 
System  Name . 

From  this  screen,  the  user  can  select,  insert,  modify,  copy, 
or  delete  Mission/ Condition  Set  files. 

User  Actions; 

The  commands  and  processes  that  are  available  are  identical 
to  those  described  for  screen  0.24. 

select  Next  screen  is  0.56. 

insert,  modify,  copy,  delete  -  See  screen  0.24. 

<ESC>  Returns  the  user  to  screen  0.53. 
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MDft> Id  System 


MODE:  Wo 


Screen  0.59  -  MDA  Utilities  menu. 

From  this  menu,  the  user  can  use  normal  menu  selection 
procedures  to  choose  a  utility  function. 

User  Action! 

1.  Directory  -  Next  screen  is  0.60. 

2.  Delete  -  Next  screen  is  0.61. 

3.  Copy  -  Next  screen  is  0.62. 

4.  Print  -  Next  screen  is  0.63. 

5.  Settings  -  Next  screen  is  0.65. 

<ESC>  Returns  the  user  to  screen  0.2. 
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PATH  :  MDA>  Lit  i  1  i  t  i  bb 


MODE:  Work 


MDA  Sy Bb  em  Ut i 1 i t i es 


1.  Directory  Listing 
£.  Delete  Files 
3.  Copy  Files 

4-  Print  Files 

5-  Settings 


Screen  0.50  -  MDA  Utilities  menu. 
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Screen  0.60  -  Directory  listing  of  all  system  names  currently 
being  evaluated. 

This  is  an  informational  screen.  The  only  user  action  is  to 

page  back  and  forth  through  the  list  of  saved  system  files. 

User  Actions; 

<PgDn>  Displays  the  next  page  of  system  names  stored  on 
the  current  disk  (if  there  is  one) . 

<PgUp>  Displays  the  previous  page  of  system  names  stored 
on  the  current  disk  (if  there  is  one) . 

<ESC>  Returns  the  user  to  screen  0.59. 
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PATH:  MDR> Utilities 


MODE;  Wor-k 


MDft  SYSTEMS  DIRECTORY 

System  Name: 

Date  Created: 

1.  UH-60  Black  Hawk 

02/03/87 

E .  UH— 1  I roq  no i s 

OEV 10/37 

3.  Ppache 

OE/ 11/87 

4.  ftH-lS  Cobra 

03/10/87 

5.  MSO  Tank 

03/E6/87 

Screen  O.CO  - 


Directory  listing  of  all  system  names  currently 
being  evaluated. 
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Screen  0.61 


Delete  System  Files  message. 


Prompts  the  user  to  enter  the  name  of  the  system  whose  files 
that  he  or  she  wants  to  delete.  This  utility  will  delete 
all  of  the  files  that  are  associated  with  the  system  name 
entered. 

User  Actions; 

Using  normal  editing  keys  and  procedures  the  user  will  enter 
the  name  of  the  system  files  to  be  deleted.  Next  screen  is 
0.61A. 


<ESC>  Returns  the  user  to  screen  0.59. 
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Lit  i  1  it  ies 


MODE:  Work 


3-128 


Screen  0.61A  -  Delete  Verification  message. 

Before  the  files  for  any  system  can  be  deleted,  the  user 
must  verify  the  delete  request. 

User  Actions; 

Y  Confirms  the  delete  request.  Next  screen  is  0.59. 

N  Cancels  the  delete  request.  Next  screen  is  0.59. 
<ESC>  Cancels  the  delete  request.  Next  screen  is  0.59. 


3-129 


PATH :  MDR>  Utilities 


MODE:  Work 


DELETE  SYSTEM  FILES 


Enter  System  Name  to  delete:  UH--60  Black  Hawk 


WARNING  ! 


If  you  continue  this  operation,  all  of 
files  associated  with  the  current  System 
name  will  be  permanently  deleted  from  the 
d  i  s  k  - 

OK  to  continue  ?  Y  or  N 


Screen  0.G1A  -  Delete  Verification  message. 
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Screen  0.62 


Copy  message. 


Prompts  the  user  to  enter  the  name  of  a  system  whose  files 
he  or  she  wants  to  copy.  The  copy  utility  will  copy  all  of 
the  files  that  are  associated  with  a  system  name. 

User  Actions; 

Using  normal  editing  keys  and  procedures,  the  user  will 
enter  a  system  name.  Next  screen  is  0.62 A. 

<ESC>  Returns  the  user  to  screen  0.59. 
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ATH;  MDA> Utilities 


MODE:  W 


Screen  0.62  - 


Copy  message. 
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Screen  0.62A  -  Copy  message  -  target  system  name. 

After  the  user  has  enter  the  name  of  a  system  to  copy,  the 
system  will  prompt  the  user  to  enter  a  target  system  name 
for  the  new  files. 

User  Actions; 

Using  normal  editing  keys  and  procedures,  the  user  will 
enter  a  target  system  name. 

<ESC>  Returns  the  user  screen  0.59. 
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MD«>  Utilities 


COPY  SYSTEM  FILES 

Enter  Source 

System 

Name ;  UH-60 

Black 

Hawk 

Enter  Target 

System 

Name :  UH-60 

Black 

HawkE 

Screen  0.62A  -  Copy  message  -  target  system  name, 


MODE:  Work 


Screen  0.63 


Print  File  menu. 


Displays  a  list  of  all  of  the  files  stored  on  the  current 
hard  disk.  From  this  list,  the  user  can  select  a  file  to 
print . 

User  Actions; 

Using  normal  menu  selection  procedures,  the  user  will  choose 
a  file  to  print.  Next  screen  is  0.63A. 

<ESC>  Returns  the  user  to  screen  0.59. 
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MDft) utilities 


■ 


PRINT  SYSTEM  FILES 


j  File  Name:  Size:  Date  Created 


1.  UH-60.CMP 

21344 

12/25/87 

a.  UH-60. SCN 

16238 

12/28/87 

3.  M60. CMP 

12899 

10/29/87 

4-  M60.SCN 

8765 

11/01/87 

5-  MGO. TSK 

10998 

11/14/87 

6.  PH- IS- CMP 

123688 

11/24/87 

select 

Screen  0.63  - 


Print  File  menu. 


Screen  0.63A  -  Print  File  menu  with  "PRINTING”  message  displayed. 


User  Actions; 

None  Next  screen  is  0.59. 
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PTH: 


h1Dft>Ut  ilit  iBB 


MOD 


PRINT  SYSTEM  FILES 

File  Name: 

Size: 

Date  Created: 

1.  UH-60.CMP 

12/25/87 

2.  UH-60.  SON 

12/28/87 

3.  M60. CMP 

PRINTING 

10/29/87 

4.  M60. SCN 

11/01/87 

5.  M60- TSK 

11/14/87 

6.  PH- IS. CMP 

123688 

11/24/87 

1 

1  select 

Screen  0.63A  -  Print  File  menu  with  "PRINTING"  message  displayed. 


3- 


Screen  0.64  -  Settings 


User  Actions; 

The  system  will  ask  user  to  identify  the  correct  MDA 
settings  for  the  type  of  printers  they  have,  any  relevant 
system  configuration  information,  and  to  identify  forground 
and  background  colors  for  all  of  the  menus  and  command  bar 
structures.  The  user  will  be  able  to  revert  to  the  default 
settings  at  any  time.  Wh^n  the  user  has  finished  modifying 
the  default  settings,  he  or  she  is  returned  to  screen  0.59. 

<ESC>  Returns  the  user  to  screen  0.59. 
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3.5  STEPS  IN  APPLYING  THE  MAINTENANCE  MANPOWER  ANALYSIS  AID 

In  order  to  use  the  MMAA  to  analyze  the  maintenance 
requirements  for  a  proposed  new  system,  the  user  will  perform 
four  general  activities: 

o  Estimate  the  maintenance  parameters  for  each 
component  in  the  system. 

o  Identify  the  maintenance  scenario  for  the 
evaluation. 

o  Execute  the  maintenance  requirements  simulation 
model . 

o  Analyze  the  results  of  the  simulation  model. 


In  order  to  accomplish  each  of  the  four  general  activities 
listed  above,  the  user  will  follow  the  eight  specific  steps 
listed  below. 

1.  Enter  the  system  component  names  and  all  available 
maintenance  parameters  from  the  contractor's 
system  design. 

Match  system  components  and  parameters  from  the 
contractor's  design  to  government  baseline 
estimates  from  comparable  fielded  systems. 

Ic^nti^y  descrepancies  between  government  baseline 
estimates  and  the  contractor's  estimates  of 
component  maintenance  parameters. 
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4.  Resolve  the  identified  descrepancies  to  determine 
the  "best  estimates"  of  component  maintenance 
parameters . 

5.  Identify/develop  parameters  for  each  maintenance 
scenario  to  be  analyzed  in  terms  of  maintenance 
manpower  requirements. 

6.  Execute  the  computer  simulation  to  calculate  the 
maintenance  manhour  and  headcount  requirements  for 
the  proposed  system. 

7.  Evaluate  the  results  of  the  simulation  in  terms  of 
the  maintenance  jobs  that  are  required,  the  tasks 
that  make  up  each  job,  the  number  of  maintenance 
manhours  required,  the  maintenance  headcount 
requirements,  system  availability,  and  system 
reliability.  These  requirements  are  compared  to 
the  system  performance  requirements  that  were 
identified  in  the  Product  1  SPREA  analysis  and  the 
manpower  constraints  that  were  identified  during 
the  Product  2  MCEA  analysis. 

8.  Investigate  potential  solutions  to  maintenance 
deficiencies  by  modifying  parameters  and  re¬ 
running  the  simulation  model. 

3.5.1  STEP  1  -  Enter  the  system  component  names  and  all  available 
Component  Maintenance  Parameters  (required  by  the 
MMAA)  from  the  contractor's  system  design. 

3 . 5 . 1 . 1  Input 

External  Incut;  The  contractor's  system  design 
documentation  that  is  submitted  for  evaluation  the  Program 
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Manager's  office.  Not  all  of  the  information  required  for 
the  MMAA  analysis  will  be  contained  in  the  contractor's 
documentation.  However,  this  documentation  must,  at  least, 
contain  a  list  of  all  components  in  the  proposed  new  system. 
The  contractor's  documentation  should  also  include  a 
Logistical  Support  Analysis  Record  that  should  indicate  the 
quantitative,  qualitative,  and  procedural  requirements  for 
all  planned  and  corrective  maintenance  activities.  The  user 
will  obtain,  from  the  system  design,  as  many  of  the 
following  parameters  for  each  component: 

o  the  functional  system  to  which  the  component 
belongs . 

o  the  component  name 

o  each  maintenance  action  required 

o  the  type  of  maintenance  personnel  required  to 

perfora  the  maintenance  (e.g.  electrican, 

MOS/Skill  level) 

o  the  type  of  maintenance  (.planned  or  corrective) 

o  the  mean  operational  units  between  failure 

o  the  operational  units  metric  (miles,  time,  rounds 
fire) 

o  maintenance  mean  time  to  repair 

o  the  maintenance  organization  (ds,  gs,  etc.) 

o  an  indication  of  whether  or  not  failure  of  the 
component  will  cause  the  mission  to  be  aborted. 

NOTE:  This  description  of  input  data  from  the  system  design 
represents  a  "best  case"  situation.  In  reality,  the 
contractor  may  supply  only  a  portion  of  the  above  data. 


Internal  Input:  The  MMAA  software  and  Component  Maintenance 
Parameter  Templates. 
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3 . 5 . 1 . 2  Process 


The  user/analyst  will  gain  access  to  the  MMAA  from  the 
MDA  Flowchart  Menu.  The  screen  that  the  user  will  see,  upon 
accessing  the  MMAA  is  flowchart  menu  of  the  four  major 
activities  included  in  the  MM2\A.  The  first  four  steps  in 
the  overall  process  can  be  performed  iteratively  by  the  user 
to  identify  all  of  the  Component  Maintenance  Parameters  in 
the  system  under  evaluation.  For  example,  the  user  may  want 
to  perform  Step  1  for  all  functional  systems  in  the  system 
design  and  then  move  on  to  Step  2  for  all  functional  systems 
and  continue  until  all  four  Steps  have  been  performed  for 
all  of  the  functional  systems.  However,  it  will  also  be 
possible  for  the  user  to  perform  Steps  1-4  for  the  first 
functional  system  and  then  move  on  to  the  next  functional 
system . 

To  begin  step  1,  the  analyst  will  choose  the  "Develop 
Component  Maintenance  Parameters"  option  from  the  flowchart 
menu.  After  selection  this  option,  the  user  is  presented 
with  a  menu  that  lists  all  of  the  functional  systems  within 
the  major  system  for  which  Component  Maintenance  Parameters 
have  been  developed.  The  first  time  the  user  accesses  the 
MMAA,  the  list  will  be  blank.  From  this  screen,  the  user 
can  insert  a  new  functional  system,  modify  the  components 
and  parameters  for  an  existing  functional  system,  copy,  or 
delete  an  existing  functional  system. 

When  the  user  inserts  a  new  functional  system  or 
selects  to  modify  an  existing  functional  system,  the  MMAA 
will  display  a  Component  Maintenance  Parameters  Template  for 
that  functional  system.  The  CMP  Template  is  a  spreadsheet¬ 
like  matrix  that  has  a  space  for  component  names  in  the 
leftmost  column.  The  top  row  of  the  matrix  contains  column 
headings  that  identify  the  maintenance  parameters  required 
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for  each  component.  The  cells  that  are  the  intersection  of 
a  row  (component  name)  and  column  (maintenance  parameter) 
are  divided  into  an  upper  and  lower  portion.  In  the  upper 
portion,  the  user  will  enter  maintenance  parameter  estimates 
that  are  available  in  the  system  design.  The  lower  portion 
will  be  used  to  enter  government  baseline  estimates  in  a 
later  step.  The  analyst  will  continue  to  add  new  functional 
systems  and  enter  the  component  names  and  available 
Component  Maintenance  Parameters  for  each  new  functional 
system  until  all  of  the  components  in  the  system  design  have 
been  entered. 

The  flow  diagrams  of  the  process  of  performing  step  1 
are  included  on  the  following  pages. 
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MMAA  Step  1 

Page  1  of  3 


yes 
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MMAA  Step  1 

Page  2  of  3 


46 
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3 . 5 . 1 . 3  Output 


The  output  of  this  step  will  be  a  set  of  Component 
Maintenance  Parameter  Templates  that  are  stored  as  records 
in  the  Component  Maintenance  Parameters  data  file  for  the 
current  system.  There  will  be  one  Template  (record)  for 
each  functional  system  in  the  system  design.  Each  Template 
will  contain  a  list  of  the  component  names  and  the  Component 
Maintenance  Parameters  for  each  component  that  are  available 
in  the  system  design. 

3. 5. 1.4  User  Interface 

The  user  interfaces  that  apply  to  this  step  are 
described  in  detail  on  the  following  pages.  Please  note 
that  all  screens  for  the  MMAA  are  labeled  "Screen  l.X". 
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Screen  1.1 


Flowchart  Menu  for  the  MMAA. 


This  screen  is  a  menu  of  the  activities  that  the  user 
will  perform  in  conducting  a  maintenance  manpower 
requirements  analysis  for  a  new  system  design.  The 
arrows  on  the  flowchart  menu  indicate  the  order  in 
which  the  activities  will  be  performed.  The  use  can 
use  the  arrow  keys  and  normal  selection  procedures  to 
make  a  selection. 

User  Actions; 

1.  Develop  Component  Maintenance  Parameters.  Next 
screen  is  1.5. 

2.  Develop  Maintenance  Scenario.  When  this  option  is 
selected,  the  system  will  read  the  functional 
system  and  component  names  from  the  Component 
Maintenance  Parameter  file.  Therefore,  this 
option  should  not  be  selected  until  all  of  the 
Component  Maintenance  Parameters  have  been  entered 
(option  1).  Next  screen  is  1.68.  If  no  Component 
Maintenance  Parameters  have  been  developed,  an 
warning  message  will  display  indicating  that  the 
CMPs  should  be  entered  first. 

3.  Execute  Maintenance  Simulation.  Next  screen  is 
1.81.  If  no  Component  Maintenance  Parameters  have 
been  developed  or  if  no  Maintenance  Scenario  file 
has  been  developed,  an  error  message  displays. 

4.  Analyze  Simulation  Results.  The  simulation  model 
must  have  been  executed  prior  to  selecting  this 
option.  Next  screen  is  1.89.  If  the  simulation 
has  not  been  executed  for  this  system.  An  error 
message  indicating  such  will  display. 
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FLOWCHART  FOR  THE  MAINTENANCE  MANPOWER  ANALYSIS  AID 


Screen  1.1  -  Flowchart  Menu  for  the  MMAA. 
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Screen  1.5  -  List  of  Functional  Systems. 

This  screen  list  all  of  the  currently  created  (saved) 
functional  system  templates.  The  first  time  the  user 
accesses  this  screen  the  list  will  be  blank.  From  this 
screen,  the  user  can  use  normal  (generic)  menu/command 
selection  strategies  to  insert,  modify,  copy,  or  delete 
a  functional  system  template. 

User  Actions: 

insert  When  the  insert  command  is  highlighted,  the 
user  can  use  normal  strategies  to  choose  the 
functional  system  name  after  which  a  new 
functional  system  will  be  inserted.  Next 
screen  is  1.10. 

modify  When  the  modify  command  is  highlighted,  the 
user  can  use  normal  stragegies  to  choose  a 
functional,  system  for  which  to  add  or  modify 
components  and/or  maintenance  parameters . 

When  a  name  system  is  selected  the  Component 
Maintenance  Parameter  Template  for  that 
functional  system  will  display.  Next  screen 
is  1.31. 

copy  When  the  copy  command  is  highlighted,  the 

user  can  make  and  exact  copy  of  a  the 
selected  funcional  system  template  under  a 
new  name.  The  name  of  the  new  system  is 
displayed  directly  below  the  copied  system  in 
the  list.  Next  screen  is  1.22. 

delete  When  the  delete  command  is  highlighted,  the 
user  can  use  normal  strategies  to  choose  a 
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<ESC> 


functional  system  template  to  delete  from  the 
disk.  Next  screen  is  1.29. 


Returns  the  user  to  screen  1.1. 

Input  File; 

Component  Maintenance  Parameter  file  for  the  identified 
system. 
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PATH:  MDP>  MMAP>  Component  Maintenance  Parameters) 


MODE;  Work 


LIST  OF  FUNCTIONAL  SYSTEMS 


Im  Hydraulics  System 
£.  Electrical  System 
3.  Communications  System 


insert  modify  copy  delete 


Screen  1.5  -  List  of  Functional  Systems. 
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Screen  1.10 


List  of  Functional  Systems  with  a  blank  field 
displayed  at  the  insert  position  and  the 
"type-in”  and  "select"  commands  displayed. 

From  this  screen,  the  user  can  choose  to  type-in  a  new 
functional  system  name  or  to  select  a  new  functional 
system  name  from  a  generic  list  of  functional  systems 
for  the  identified  System  Type. 

User  Actions; 

type-in  When  this  is  the  selected  command,  a  flashing 
cursor  will  be  displayed  at  the  insertion 
point.  Next  screen  is  1.11. 

select  When  this  is  the  selected  command,  a  list  of 
generic  functional  systems  for  the  current 
System  Type  displays.  Next  screen  is  1.12. 

<ESC>  Returns  the  user  to  screen  1.5,. 
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MODE:  Work 


PATH:  MDA>  MMAA) Component  Maintenance  Parameters) 


LIST  OF  FUNCTIONAL  SYSTEMS 


1.  Hydraulics  System 
£-  Electrical  System 
3»  Communications  System 

4. 


type-in  select 


Screen  1.10 


List  of  Functional  Systems  with  a  blank  field 
displayed  at  the  insert  position  and  the  "type- 
in"  and  "select"  commands  displayed. 
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Screen  1.11  -  List  of  Functional  Systems  with  a  flashing 
cursor  displayed  at  the  insertion  point. 

From  this  screen,  the  user  can  type-in  the  name  of  a 
new  functional  system. 

User  Actions; 

The  user  will  use  normal  editing  keys  and  procedures  to 
enter  the  name  of  a  functional  system  of  components  for 
the  system  under  evaluation  such  as  the  avionics  system 
or  the  electrical  system.  The  string  of  characters 
that  constitute  the  name  will  be  terminated  by  pressing 
the  <ENTER>  key.  When  the  new  system  name  has  been 
entered,  the  system  will  display  a  blank  Component 
Maintenance  Parameter  Template  for  the  inserted 
functional  system  name.  Next  screen  is  30A?? 

<ESC>  Returns  the  user  to  screen  1.10. 
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PPTH:  MDfi>  MMAft>  Component  Maintenance  Parameters) 


MODE:  Work 


LIST  OF  FUNCTIONAL  SYSTEMS 


!•  Hydraulics  System 
£-  Electrical  System 
3m  Comrnunicat  ions  System 

4.  ^ 


type— in 


select 


Screen  1.11  - 


List  of  Functional  Systems  with  a  flashing  cursor 
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Screen  1.12  -  Generic  Functional  Systems  List  for  the 
identified  System  Type. 

From  this  screen,  the  user  can  select  a  name  for  the 
functional  system  template  to  be  inserted. 

User  Actions; 

Using  normal  menu  selection  procedures,  the  user  can 
choose  a  functional  system  name.  Next  screen  is  1.30A. 

<ESC>  Returns  the  user  to  screen  1.10. 

Input  File! 

Product  5  Generic  Equipment  by  System  Type  file. 
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PATH:  MDA>  MMftft) Component  Maintenance  Parameters) 


MODE:  Work 


LIST  OF  FUNCTIONAL  SYSTEMS 


1.  Hydraulics  System 
£•  Electrical  System 
3-  Communications  System 

4. 


type— in 


select 


GENERIC  FUNCTIONAL  SYSTEM  LIST 
FOR:  UTILITY  HELICOPTERS 


4. 

5- 

6. 

7- 

8. 

9. 

0. 


Hydraulic  System 
E 1 ect  r i ca 1  Sy st  ern 
Comrnunicat  ions  System 
Engine 


More 


Screen  1.12  - 


Generic  Functional  Systems  List  for  the  identified 
System  Type. 
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Screen  1.22  -  List  of  Functional  Systems  with  a  flashing 

cursor  displayed  in  the  field  directly  below 
the  Functional  System  Template  to  be  copied. 

From  this  screen,  the  user  can  enter  the  name  of  a  new 
functional  system. 

User  Actions! 

Using  normal  editing  keys  and  procedures,  the  user  can 
enter  a  new  fxinctional  system  name  for  the  copy.  Next 
screen  is  1.23. 


<ESC>  Returns  the  user  to  screen  1.5. 


PftTH :  MDP> MMflfi) Component  Maintenance  Parameters) 


MODE:  Work 


LIST  OF  FUNCTIONFIL  SYSTEMS 

1. 

Hydraul ics  System 

£- 

E 1  ect  r  i  ca  1  By  st  ern 

3m 

Comrnun  i  cat  i  ons  Sy st  ern 

4. 

Engine 

5. 

insert  modify  copy  delete 

Screen  1.22  - 


List  of  Functional  Systems  with  a  flashing  cursor 
displayed  In  the  field  directly  below  the 
Functional  System  Template  to  be  copied. 
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Screen  1.23 


List  of  Functional  Systems  with  a  delete 
verification  message  displayed. 

From  this  screen,  the  user  must  either  verify  or  cancel 
the  delete  command. 

User  Actions: 

Y  Confirms  the  delete  operation.  Next  screen  is 

1.5. 

N  Cancels  the  delete  request.  Next  screen  is  1.5. 
<ESC>  Cancels  the  delete  request.  Next  screen  is  1.5. 


PATH:  MDA>  MMAA)  Cornponerit  Maintenance  Parameters) 


MODE:  Work 


LIST  OF  FUNCTION 


1.  Hydraulics  System 
Electrical  System 

3.  Communications  Sy 

4.  Engine 

5.  Engines 


_ 1 

insert 

mod i f y 

copy 

delete 

WARNING:  If  you  delete  a 

functional  system,  you’ll 
also  delete  all  of  the 
components  and  parameters 
associated  with  it. 

□K  to  delete  ?  (y  or  n) 


List  of  Functional  Systems  with 
verification  message  displayed. 


delete 
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Screen  1.30A  -  Blank  Component  Maintenance  Parameter 

Template  for  the  inserted  functional  system. 

From  this  screen,  the  user  can  use  normal  template 
editing  keys  and  procedures  to  enter  the  name  of  each 
component  in  the  functional  system  from  the 
contractor's  design  and  enter  all  of  the  available 
Component  Maintenance  Parameters  that  are  included  in 
the  design  docimentation. 

User  Actions; 

Using  normal  editing  procedures,  the  user  will  enter 
all  of  the  components  and  available  maintenance 
parameters  that  were  obtained  from  the  contractors 
design  documents.  See  section  3.1. 

When  the  user  has  finished  entering  the  component  names 
and  parameters  from  the  system  design,  he  or  she  can 
press  the  <ESC>  key  to  return  screen  1.5  and  choose  a 
new  functional  system  to  work  on  or  move  on  to  Step  2 . 


PftTH  :  MDA>  MMPA>  Cornporient  Mainteriance  Parerneters 


MODE;  Work 


more 


System  name;  LIH-60  Black  Hawk  Functional  System;  Engine 

Component 

Name 

Maintenance 
Act i on 

MOS/Skill 

Type 

<P/C) 

MOUBF 

Operational 
Unit  Metric 

■r 

! 

i 

i 

! 

Screen  1.30/.  - 


Blank  Component  Maintenance  Parameter  Template 

for  the  inserted  functional  system. 
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Screen  1.31  -  Component  Maintenance  Parameter  Template  with 
some  information  entered. 

From  this  screen,  the  user  can  enter  or  modify 
information  from  the  system  design,  press  the  <ESC>  key 
to  return  to  screen  1.5  and  choose  a  new  functional 
system  to  work  on  or  move  on  to  step  2. 


PATH:  MDA>  MMAA>  Cornporient  Mairit enance  Parerneters 


MODE:  Work 


more 


System  name:  UH--60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
Act i on 

MOS/Skill 

Type 

<P/C) 

MOUBF 

Operational 
Unit  Metric 

Fuel  Injection 

adjust 

63D10 

c 

107.  5 

mil  es 

Cylinder  Head 

repair 

63D£0 

c 

10£0 

rn  i  1  es 

Crankshaft 

repair 

63D£0 

c 

980 

miles 

Seals,  main 

replace • 

Screen  1.31 


Component  Maintenance  Parameter  Template  with  some 
information  entered. 
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3.5.2  STEP  2  -  Match  system  components  and  parameters  from  the 
contractor's  design  to  baseline  estimates  from 
comparable  systems. 

3 . 5 . 2 . 1  Input 

External;  The  input  required  for  Step  2  is  a  list  of 
components  and  estimates  of  the  maintenance  parameters  that 
are  required  by  the  MMAA  (see  Step  1)  for  each  component 
from  comparable  fielded  systems.  Ideally,  this  information 
will  reside  in  the  Baseline  Library.  However,  when  a 
comparable  system  does  not  reside  in  the  Library  the  analyst 
will  need  to  obtain  this  information  from  the  following 
external  sources: 

o  Army  Annual  Maintenance  Manhours  Data  Base  (AMMDB) 
o  Sample  Data  Collection  Data  Base 

o  Army  equipment  inventories  of  fielded  systems 
o  System  design  specifications  for  fielded  systems 
o  Technical  manuals  for  maintenance  activities 

o  Subject  Matter  Experts 

Internal ;  The  input  for  this  step  that  is  included  within 
the  MMAA  will  be  1)  Component  Maintenance  Parameter  files 
containing  the  names  of  each  hardware/ software  component  by 
functional  system  created  in  Step  1.  2)  The  Baseline 

Library  of  Component  Maintenance  Parameters  for  fieid^ 
systems.  3)  MMAA  software. 

3 . 5 . 2 . 2  Process 

The  process  of  identifying  baseline  estimates  of  system 
Component  Maintenance  Parameters  to  be  entered  into  the 
Component  Maintenance  Parameter  Template  as  government 
estimates  is  dependent  on  the  availability  of  fielded  system 
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data  in  the  Baseline  Library.  The  user/analyst  can  enter 
government  estimates  directly  into  the  lower  portion  of  each 

cell  of  the  Component  Maintenance  Parameter  Template  using 

1 

normal  editing  procedures  or  copy  Component  Maintenance 
Parameters  from  comparable  fielded  systems  that  reside  in 
the  Baseline  Library. 

When  the  analyst  first  gains  access  to  the  Baseline 
Library,  he  or  she  will  need  to  identify  a  comparable 
baseline  system  down  to  the  functional  system  level.  When 
the  user  chooses  to  view  the  components  and  maintenance 
paremeters  for  an  identified  baseline  system,  a  Baseline 
Library  Template,  similar  to  the  Component  Maintenance 
Paremeter  Template  will  display.  From  this  template,  the 
user  can  copy  a  component  and  all  of  its  associated 
maintenance  parameters  or  a  block  of  components  and 
maintenance  parameters  into  a  buffer.  Then,  the  user  can 
return  to  the  Component  Maintenance  Parameter  Template  in 
which  he  or  she  was  working  and  copy  the  contents  of  the 
buffer  into  the  government  estimates  portion  of  the  cell  or 
cells  for  components  in  the  new  system.  This  process  is ■ 
repeated  until  all  of  the  available  baseline  estimates  have 
been  copied  from  the  Library  for  all  functional  systems  in 
the  system  under  evaluation. 

In  cases  where  data  from  a  suitable  system  does  not 
exist  in  the  Baseline  Library,  the  analyst  will  need  to 
identify  the  Component  Maintenance  Parameters  from 
comparable  systems  from  other  sources  and  enter  them 
directly  into  the  Component  Maintenance  Parameter  Template 
using  the  process  outlined  in  Step  1.  ■ 

The  flow  diagrams  of  the  process  of  performing  Step  2 
are  included  on  the  following  pages. 
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MMAA  Step  2 

Page  1  of  3 


System  Displays 
a  CMP  Template 
for  the  Current 
Functional 
System 
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3 . 5 . 2 . 3  Output 


The  output  of  this  step  will  be  a  set  of  Component 
Maintenance  Parameter  Templates  that  are  stored  as  records 
in  the  Component  Maintenance  Parameters  data  file  for  the 
current  system.  Each  record  will  contain  a  list  of  the 
component  names,  the  Component  Maintenance  Parameters  for 
each  component  that  were  available  from  the  system  design 
and  a  government  estimate  of  Component  Maintenance 
Parameters  from  comparable  fielded  systems. 

3. 5. 2. 4  User  Interface 

The  user  interfaces  that  apply  to  this  step  are 
described  in  detail  on  the  following  pages.  Please  note 
that  all  screens  for  the  MMAA  are  labeled  "Screen  l.X". 
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Screen  1.31  -  Component  Maintenance  Parameter  Template. 

Whenever  the  user  has  entered  one  or  more  components  to 
the  Component  Maintenance  Parameter  Template,  he  or  she 
can  gain  access  to  the  Baseline  Library  to  search  for  a 
comparable  system  component. 

User  Actions; 

F9  Displays  the  menu  bar  of  commands  that  are 

available  from  the  Component  Maintenance  Parameter 
Template.  Next  screen  is  1.36. 


<ESC>  Returns  the  user  to  screen  1.5. 


PATH:  MDA>  MMAA>  Cornporierit  Mai ntenance  Parernet ers 


MODE:  Work 


more 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
Act  ion 

MOS/Skill 

Type  . 
(P/C) 

MOUBF 

Operational 
Unit  Metric 

Fuel  Injection 

adjust 

63D10 

C 

107.  5 

miles 

Cylinder  Head 

repair 

c 

10£0 

mil  es 

Crankshaft 

repair 

63D20 

c 

980 

miles 

Seals,  main 

replace 

Screen  1.31 


Component  Maintenance  Parameter  Template. 
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Screen  1.36  -  Component  Maintenance  Parameter  Template  with 
menu  bar  displayed. 

From  this  screen,  the  user  can  gain  access  to  the 
Baseline  Library,  paste  one  or  more  components  and 
maintenance  parameters  copied  into  the  buffer  from  the 
Baseline  Library,  identify  tolerances  for  a  sort 
operation  (Step  3) ,  sort  the  Component  Maintenance 
Parameter  Template  for  discrepancies  (Step  3) ,  or 
report  discrepancies  found  during  the  most  recent  sort 
operation  (Step  3) . 

User  Actions; 

Access  Library  -  When  this  command  is  selected  the 
system  will  switch  the  user  to  the  Identify  Baseline 
System  menu  in  the  Baseline  Library.  Next  screen  1.37. 

Paste  -  When  this  command  is  selected,  the  system  will 
paste  the  contents  of  the  copy  buffer  into  the 
government  estimates  portion  of  the  Component 
Maintenance  Parameter  Template  at  the  current  cell 
cursor  location.  Next  screen  is  1.48. 

Id  Tolerances  -  When  this  command  is  selected  the  user 
will  be  able  to  change  the  tolerance  value  for  the  next 
sort  operation  (Step  3).  Next  screen  is  1.52. 

Sort  “  When  this  command  is  selected,  the  system  will 
begin  a  sort  operation  (Step  3).  Next  screen  is  1.55.' 

Report  -  When  this  command  is  selected,  the  user  will 
be  able  to  get  a  report  of  the  results  of  the  most 
recent  sort  operation  (Step  3).  Next  screen  is  1.58. 

<ESC>  Returns  the  user  to  screen  1.31. 
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PftTH  :  MDA>  NMAA)  Cornponerit  Maintenance  Parerneters 
Access  Library  Paste  Id  Tolerances 

Gain  access  to  Baseline  Library  to  select  comparable 


MODE: 

Sort 

syst  ern  component  s 


Work 

Report 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
Act i on 

MOS/Skill 

Type 

<P/C) 

MOUBF 

Operat ional 
Unit  Metric 

1 

Fuel  Injection 

adjust 

63D10 

c 

107.  5 

miles 

Cylinder  Head 

repair 

63D20 

c 

1020 

mi  les 

Crankshaft 

repair 

miles 

Seals,  main 

replace 

Screen  1.36  - 


Component  Maintenance  Parameter  Template  with,  menu 
bar  displayed. 
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Screen  1.37  -  Identify  Baseline  System  menu. 

This  menu  displays  the  Mission  Area,  System  Type  and 
Functional  System  name  from  the  current  Component 
Maintenance  Parameters  Template  as  default  values.  The 
user  can  change  any  of  these  fields  or  select  the 
System  Name  field  to  identify  a  comparable  system. 

User  Actions; 

1.  Mission  Area  -  Next  screen  is  1.39. 

2.  System  Type  -  A  menu  of  System  Types  for  the 
identified  Mission  Area  displays.  Next  screen  is 
39A??. 

3 .  System  Name  -  A  list  of  System  Names  that  reside  in 
the  Baseline  Library  for  the  identified  System  Type 
displays.  Next  screen  is  1.40.  If  a  System  Type  has 
not  been  identified,  an  error  message  displays. 

4.  Functional  System  -  A  list  of  functional  systems  for 
the  identified  System  Name  displays.  Next  screen  is 
1.42.  If  a  System  Name  has  not  been  identified,  an 
error  message  displays. 

5.  View  System  Components  -  A  matrix  of  components  and 
Component  Maintenance  Parameters  from  the  Baseline 
Library  displays.  Next  screen  is  1.43.  If  a 
functional  system  has  not  been  identified,  an  error 
message  displays. 
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PATH:  Baseline  Library) 


MODE:  Work 


Screen  1.37  Identify  Baseline  System  menu. 
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Screen  1.39  -  Mission  Area  List. 

From  this  menu,  the  user  can  select  a  Mission  Area  to 
begin  the  search  for  a  baseline  system. 

User  Actions; 

Using  normal  menu  selection  procedures  the  user  will 
select  a  Mission  Area  from  the  list.  Next  screen  is 
1.37. 

<ESC>  Returns  the  user  to  screen  1.37. 

Input  File; 

Product  5  Missions  by  System  Type  Taxonomy  file. 
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PATH:  Baseline  Library) 


MODE:  Work 


IDENTIFY  BASELINE  SYSTEM 


1.  Mission  Area:  Aviation 
£.  System  Type:  Utility  H 

3.  System  Name: 

4.  Functional  System:  Engi 

5.  View  System  Components 


MISSION  flREft 

LIST 

1. 

ftir  Defense 

2. 

Aviat ion 

w 

Combat  Service  Support 

4. 

Close  Combat 

Light 

5. 

Close  Combat 

Heavy 

6. 

Fire  Support 

7. 

Cancel 

Screen  1.39  -  Mission  Area  List. 
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Screen  1.39A  -  List  of  System  Types  for  the  identified 
Mission  Area. 

From  this  screen,  the  user  can  select  a  System  Type  for 
the  Baseline  Library  search  for  a  comparable  system. 

User  Actions: 

Using  normal  menu  selection  procedures,  the  user  can 
choose  a  System  Type.  Next  screen  is  1.37. 

<ESC>  Returns  the  user  to  screen  1.37  with  no  change  to 
the  System  Type  field. 

Input  File! 

Product  5  Missions  by  System  Type  Taxonomy  file. 
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cn  >  o-i  ro 


PATH:  Baseline  Library> 


MODE:  Work 


IDENTIFY  BASELINE  SYSTEM 


Aviat ion 

Utility  He 1 i copt  ers 


Mission  Area: 

System  Type: 

System  Name: 

Functional  System:  Engine 
View  System  Components 


AVIATION  SYSTEM  TYPES 

1. 

Attack  Hel i copt ers 

£. 

Cargo 

Helicopters 

3. 

Utility  Helicopters 

4. 

Scout 

Hel icopters 

Other 

Hel icopters 

6. 

Fixed 

Wing 

List  of  System  Types  for  the  identified  Mission 
Area. 
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Screen  1.39A  - 


Screen  1.40  -  List  System  Names  that  reside  in  the  Baseline 
Library  for  the  identified  System  Type. 

From  this  screen,  the  user  can  select  a  System  Type  to 
search  for  comparable  components. 

User  Actions: 

Using  normal  menu  selection  procedures  the  user  can 
select  a  System  Name.  Next  screen  is  1.41. 

Input  File; 

Product  5  MMAA  Baseline  Library. 


PATH:  Baseline  Libnany) 


MODE:  Work 


Screen  1.40  - 


List  System  Names  that  reside  in  the  Baseline 
Library  for  the  identified  System  Type. 
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Screen  1.41  -  Identify  Baseline  System  menu  with  Mission 
Area,  System  Type,  System  Name,  and 
Functional  System  identified. 

From  this  screen,  the  user  can  choose  to  view 
components  and  maintenance  parameters  for  the 
identified  functional  system  from  the  Baseline  Library 
or  identify  a  new  comparable  system  to  the  functional 
system  level. 

User  Actions; 

1.  Mission  Area.  Next  screen  is  1.39. 

2.  System  Type  -  Next  screen  is  1.39A??. 

3.  System  Name  -  Next  screen  is  1.40. 

4.  Functional  System  -  1.42. 

5.  View  System  Components  -  The  system  displays  a 
matrix  of  components  and  maintenance  parameters  for  the 
identified  functional  system.  Next  screen  is  .143. 

<ESC>  Returns  the  user  to  the  Component  Maintenance 
Paremeter  Template  for  the  current  functional  system. 
Next  screen  is  1.36. 
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PPTH:  Baseline  Library) 


MODE:  Work 


IDENTIFY  BASELINE  SYSTEM 


1.  Mission  Area:  Aviation 
£•  System  Type:  Utility  Helicopters 

3.  System  Name:  UH'-SO  Black  Hawk 

4.  Functional  System:  Engine 

5.  View  System  Components 


Screen  1.41  - 


Identify  Baseline  System  menu  with  Mission  Area, 
System  Type,  System  Name,  and  Functional  System 
identified. 
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Screen  1.42.  -  Functional  System  list  for  the  identified 
System  Name . 

From  this  screen,  the  user  can  select  a  functional 
system  to  search  for  components  and  maintenance 
parameters  that  are  comparable  to  those  in  the  system 
under  evaluation. 

User  Actions; 

Using  normal  menu  selection  procedures,  the  user  can 
select  a  functional  system.  Next  screen  is  1.41, 

<ESC>  Returns  the  user  to  screen  1.41. 

Input  File! 

Product  5  MMAA  Baseline  Library. 
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Basel ine  Library) 


MODE:  Work 


IDENTIFY  BASELINE  SYSTEM 


Mission  Area:  Aviation 
System  Type:  Utility  Helic 
System  Name:  UH-60  Black  H 
Functional  System:  Engine 
View  System  Components 


FUNCTIONAL  SYSTEM  LIST  F( 

□R; 

UH- 

60  BLACK  HAWK 

1. 

Hydraul ic 

C!  m 

Electrical 

3. 

Communicat 

ions 

4- 

Fire  Contr 

III 

5. 

Engine 

&. 

m 

7. 

m 

a. 

m 

9. 

0. 

m 

More 

_ L 

Screen  1.42.  -  Functional  System  list  for  the  Identified  Syst 


Screen  1.43  -  Matrix  of  components  names  and  maintenance 
parameters  for  the  selected  functional 
system . 

From  this  screen  the  user  can  use  normal  cursor 
movement  functionality  to  view  each  of  the  components 
and  its  associated  maintenance  parameters  in  the 
matrix.  When  the  user  is  ready  to  copy  one  or  more 
components  into  the  buffer,  he  or  she  will  highlight 
that  component.  The  cell  cursor  in  the  Baseline 
Library  will  always  highlight  a  component  and  all  of 
its  maintenance  parameters  since  the  copy  operation 
will  always  copy  all  of  the  maintenance  parameters  for 
a  component.  To  highlight  a  block  of  components,  the 
user  will  move  the  cell  highlight  cursor  to  the  first 
component  in  the  block  and  then  press  the  <ENTER>  key. 
This  will  "anchor”  the  highlighting.  Then  the  user  can 
use  the  up  or  down  arrow  keys  to  highlight  additional 
components  and  their  maintenance  parameters. 

User  Actions: 

Using  the  cell  highlighting  procedures  outlined  above, 
the  user  will  highlight  cells. 

F9  -  Will  display  a  menu  bar  of  commands  that  are 
available  from  this  matrix.  Next  screen  is  1.44. 

<ESC>  When  a  block  of  components  is  highlighted,  this 
key  will  de-highlight  all  but  the  first  component  in 
the  block.  When  only  one  component  is  highlighted, 
pressing  this  key  will  return  the  user  to  screen  1.41. 

Input  File; 

Product  5  MMAA  Baseline  Library. 


3-190 


PATH;  Baseline  Library 


MODE:  Work 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
Act i on 

MOS/Skill 

Type 

(P/C) 

MOUBF 

Operat ional 

Un i t  Met  r i c 

F  ue 1  I nj  ect i on 

adjust 

63D10 

c 

107.  5 

miles 

Cylinder  Head 

replace 

63D10 

C 

1500 

miles 

Crankshaft 

repair 

63D£0 

c 

1 1£0 

mil  es 

Seals,  main 

replace 

63D10 

c 

1000 

mi  les 

Master  cylinder 

repair 

63D£0 

c 

mi[m 

rn  i  1  es 

.  Battery  Pack 

replace 

43D20 

c 

t  irne 

Rod,  connecting 

inspect 

63DE0 

p 

4500 

miles 

Rod ,  connect i ng 

replace 

63D30 

c 

1  £500 

miles 

Screen  1.43  -  Matrix  of  components  names  and  maintenance 
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Screen  1.44  -  Matrix  of  components  names  and  maintenance 

parameters  for  the  selected  functional  system 
with  menu  bar  commands  displayed. 

From  this  screen,  the  user  can  select  and  initiate  any 
of  the  displayed  commands. 

User  Action: 

Copy  -  When  the  copy  command  is  selected,  the  system 
will  copy  all  highlighted  components  and  their 
maintenance  parameters  into  the  copy  buffer.  Any 
information  already  in  the  buffer  will  be  lost.  The 
screen  remains  the  same. 

Describe  -  When  this  command  is  selected,  the  system 
will  display  a  detailed  description  of  the  highlighted 
component.  An  example  of  the  screen  that  will  follow 
is  screen  1.45.  If  a  block  of  components  is  currently 
highlighted  the  system  will  display  ah  error  message, 
telling  the  user  to  highlight  only  one  component  when 
selecting  the  describe  command. 

Switch  -  When  this  command  is  selected,  the  system  will 
switch  the  user  back  to  the  current  Component 
Maintenance  Parameter  Template.  Next  screen  is  1.32. 

Id  New  System  -  When  this  command  is  selected,  the 
system  will  return  the  user  to  the  Identify  Baseline 
System  menu.  Next  screen  is  1.41. 

<ESC>  Returns  the  user  to  screen  1.43. 
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MODE:  Work 


PATH:  Baseline  Library 

Copy  Describe  Switch  Id  new  system 

Copy  highlighted  components  and  parameters 


System  name:  UH-60  Black  Hawk 


Functional  System:  Engine 


Component 

Name 


Maintenance 
Pet i on 


MOS/Skill 


Type 

<P/C) 


MOUBF 


Operat ional 
Unit  Metric 


Fuel  Injection 


adjust 


63D10 


107. 


mi  les 


Cylinder  Head 


replace 


63D10 


1500 


miles 


Crankshaft 


repair 


63D20 


1 1 EO 


mi  les 


Seals,  main 


replace 


63D10 


1 000 


rn  i  1  es 


Mast  er  cy 1 i nder 


repair 


63DE0 


E500 


miles 


Battery  Pack 


replace 


43DE0 


750 


t  irne 


Rod ,  connect i ng 


inspect 


63DE0 


4500 


miles 


Rod,  connecting 


replace 


63D30 


1E500 


mi  les 


Screen  1.44  -  Matrix  of  components  names  and  maintenance 

parameters  for  the  selected  functional  system  with 
menu  bar  commands  displayed. 


3-193 


Screen  1.45  -  Detailed  description  of  a  component  in  the 
Baseline  Library. 

This  is  a  purely  informational  screen  to  help  the  user 
decide  if  this  is  truly  a  comparable,  component  to  one 
in  the  system  under  evaluation. 

User  Actions; 

The  only  two  user  actions  that  are  available  from  this 
screen  are  the  following: 

<ENTER>  Returns  the  user  to  screen  1.43. 

<ESC>  Returns  the  user  to  screen  1.43. 

Input  File: 

Product  5  MMAA  Baseline  Library. 
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PftTH:  Baseline  Library  MODE:  Work 

Copy  Describe  Switch  Id  new  system 

Present  a  detailed  description  of  the  highlighted  component 


System  name:  UH-60  Black  Hawk 

Component 

Name 

Maintenance 
Act  ion 

Fuel  Injection 

adjust 

Cylinder  Head 

replace 

Crankshaft 

repair 

Seals,  main 

replace 

Master  cylinder 

llligggg 

Battery  Pack 

replace 

Rod ,  connect i ng 


Rod',  connecting 


FUEL  INJECTION 


Detailed  description  of  the 
fuel  injection  component 
including  the  size,  MIL  spec  # 
manufacturer  and  any  other 
identifying  information  that 
is  applicable  and  available 


inspect 


replace 


63D30 


12500 


mi  les 


Screen  1.45  -  Detailed  description  of  a  component  in  the 
Baseline  Library. 


Screen  1.48  -  Component  Maintenance  Parameter  Template  with 
baseline  maintenance  parameters  copied  from 
the  Baseline  Library  pasted  into  the 
government  estimates  portion  of  a  cell. 

User  Actions! 

The  actions  that  are  available  to  the  user  from  this 
screen  are  the  same  as  those  available  from  screen 
1.36. 
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PATH:  MDP>  MMPP>  Cornponerit  Mai nt enance  Parerneters  MODE:  Work 

Pccess  Library  Paste  Id  Tolerances  Sort  Report 

Retrieve  the  maintenance  parameters  for  one  or  more  Baseline  components 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 


Component 

Name 


Fuel  Injection 


Cylinder  Head 


Crankshaft 


Seals,  main 


Screen  1.48  - 


Component  Maintenance  Parameter  Template  with 
baseline  maintenance  parameters  copied  from  the 
Baseline  Library  pasted  into  the  government 
estimates  portion  of  a  cell. 
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3.5.3  STEP  3  -  Identify  discrepancies  between  the  government 
baseline  estimates  and  the  contractor's  design 
estimates  of  Component  Maintenance  Parameters. 

3 . 5 . 3 . 1  Input 

External :  Analyst  judgement  on  the  amount  of  tolerance  he 
or  she  will  accept  for  deviations  between  the  baseline  data 
and  the  contractor's  estimates. 

Internal :  The  Component  Maintenance  Parameter  data  files 
containing  both  baseline  data  and  contractor's  estimates  of 
the  maintenance  parameters  that  were  completed  in  Step  2. 

3 . 5 . 3 . 2  Process 

The  performance  of  this  step  is  dependent  on  the 
availability  of  the  contractor's  design  estimates  for  at 
least  some  of  the  Component  Maintenance  Parameters.  When 
the  contractor's  design  dosen't  include  any  estimates  of 
Component  Maintenance  Parameters  required  by  the  MMAA,  the 
analyst  will  use  the  baseline  government  estimates  as  the 
only  input  to  the  simulation  model.  When  this  is  the  case, 
the  analyst  can  skip  this  step. 

When  the  a  Component  Maintenance  Parameters  Template 
contains  all  of  the  baseline  and  contractor  estimates  that 
are  available,  the  analyst  can  have  the  system  sort  through 
each  pair  of  estimates  for  each  component  in  the  functional 
system  to  identify  discrepancies.  However,  before  sorting 
the  Template,  the  analyst  may  want  to  change  the  tolerance 
value  that  defines  a  discrepancy.  The  default  tolerance 
value  is  10%.  This  means  that  when  the  Template  is  sorted, 
any  difference  between  the  contractor  and  government 
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estimate  that  is  within  10  persent  is  not  considered  a 
difference. 

When  the  system  has  sorted  a  Component  Maintenance 
Paremeter  Template  a  siammary  of  the  sort  operation  is 
displayed  to  the  user.  In  addition,  a  list  of  all 
identified  discrepancies  is  stored  in  a  data  file.  The  user 
can  then  have  the  system  either  print  the  list  of 
discrepancies  or  present  them  one  by  one  on  the  screen  for 
the  analyst  to  review  and  resolve  (Step) . 

The  flow  diagram  of  the  process  of  performing  Step  3 
are  included  on  the  following  page. 
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System  Moves 
Cursor  to 
Next  (first) 
di screpancy 


Save  Data  ? 


3 . 5 . 3 . 3  Output 


The  results  of  the  sort  operation  will  store  a  list  of 
the  differences  or  discrepancies  between  government  and 
contractor  estimates  of  Component  Maintenance  Parameters  for 
each  functional  system  of  the  system  under  evaluation.  Any 
sort  operation  will  only  affect  the  discrepancy  list  for 
that  functional  system.  However,  each  sort  of  the  same 
functional  system  will  replace  the  contents  of  the 
discrepancy  file  for  that  functional  system. 

3. 5. 3. 4  User  Interface 

The  user  interfaces  that  apply  to  this  step  are 
described  in  detail  on  the  following  pages.  Please  note 
that  all  screens  for  the  MMAA  are  labeled  "Screen  l.X". 
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Screen  1.52  -  Component  Maintenance  Parameters  Template 

with  Id  Tolerances  selected  on  the  menu  bar 
and  the  "Current  Percentage  Difference 
Tolerance"  prompt  displayed. 

A  flashing  cursor  is  displayed  below  the  first 
character  of  the  current  tolerance  value. 

User  Action: 

Using  normal  editing  keys  and  procedures,  the  user  can 
change  the  tolerance  value.  The  user  will  terminate 
input  by  pressing  the  <ENTER>  key.  Next  screen  is 
1.36.  If  the  tolerance  value  entered  is  not  within  the 
allowable  range,  an  error  message  will  display 
explaining  the  tolerance  range. 

<ESC>  Returns  the  user  to  screen  1.36  without  changing 
the  current  tolerance  value. 
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PATH:  MDA> MMAft) Component  Maintenance  Paremeters  MODE:  Work 

Access  Library  Paste  Id  Tolerances  Sort  Report 

Identify  percentage  differences  in  that  will  be  ignored  during  sort  operation 


System  name:  LJH-60  Black  Hawk 


Functional  System:  Engine 


Component 

Name 


I  erat ional 
it  Metric 


Current  Percentage  Difference  Tolerance:  10 


Fuel  Injection 


Cylinder  Head 


Screen  1,52  - 


Component  Maintenance  Parameters  Template  with  Id 
Tolerances  selected  on  the  menu  bar  and  the 
"Current  Percentage  Difference  Tolerance"  prompt 
displayed. 
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Screen  1.55  -  Component  Maintenance  Parameter  Template  with 
the  "Sort  operation  in  progress”  message 
displayed. 

At  this  point,  the  user  must  simply  wait  for  the  sort 
operation  to  complete. 

User  Actions; 

None.  Next  screen  is  1.56. 
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PATH:  MDA>  MMAfi>  Component  Maintenance  Parerneters  MODE:  l>Jait 

Access  Library  Paste  Id  Tolerances  Sort  Report 

Compare  contract  design  and  govt,  estimates  to  identify  discrepancies 


System  name:  UH-SO  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 

Action 

MOS/Skill 

Type 

(P/C) 

MOUBF 

□per at ional 
Unit  Metric 

Fuel  I n j  ect i on 

adjust 

I 

107.  5 

mil  es 

Sort  operation 
in  progress. 

Cylinder  Head 

repair 

1  oso 

mi  les 

_ I 

Crankshaft 

repair 

63D20 

C 

980 

miles 

Seals,  main 

replace 

Screen  1.55  - 


Component  Maintenance  Parameter  Template  with  the 
"Sort  operation  in  progress"  message  displayed. 


Screen  1.56 


Sort  operation  summary  screen. 


This  screen  is  informational  the  only  accepted  response 
is  for  the  user  to  press  the  <ENTER>  key.  Next  screen 
is  1.36. 


PATH:  MDA>  MMPA>  Cornponerit  Maintenance  Parerneters  MODE:  Work 

ftccesB  Library  Paste  Id  Tolerances  Sort  Report 

Compare  contract  design  and  govt,  estimates  to  identify  discrepancies 


System  name:  UH-60  Black  Hawk 


Functional  System:  Engine 


Cornponen 

Name 


Fuel  In.jec 


Cylinder  H 


Crankshaft 


Sort  operat ion  complete. 

£9  maintenance  actions  had  no  baseline  estimate. 
15  maintenance  actions  had  no  design  estimate. 

37  maintenance  actions  had  discrepancies  that 
were  outside  defined  tolerances. 

pY-'ess  <ENTER>  to  continue. 


rat ional 
t  Metric 


Screen  1.56  -  Sort  operation  summary  screen. 
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Screen  1.58  -  Component  Maintenance  Parameters  Template 
with  report  options  displayed  on  the  menu 
bar. 

From  this  screen,  the  user  can  choose  to  print  out  a 
list  of  the  identified  discrepancies  from  the  most 
recent  sort  operation  or  review  each  discrepancy  one  by 
one  on-line. 

User  Actions: 

Review  -  When  this  command  is  selected,  the  cell  cursor 
will  move  to  the  cell  in  the  template  where  the  first 
discrepancy  exists.  When  the  user  presses  the  <ENTER> 
key  the  cursor  will  move  to  the  cell  with  the  next 
identified  discrepancy.  An  example  of  the  next  screen 
is  1.62. 

Print  -  When  this  command  is  selected,  the  system 
begins  to  print  the  discrepancy  list,  for  the  most 
recent  sort  operation  for  this  functional  system.  Next 
screen  is  1.66. 

<ESC>  Returns  the  system  to  screen  1.36. 
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MODE:  Work 


PftTH:  MDft>  MMftft)  Component  Maintenance  Parerneters 
Review  Print  out 

Proceed  to  next  unresolved  discrepancy  in  the  template 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
ftct i on 

MOS/Skill 

Type 

(P/C) 

MOUBF 

Operat ional 
Unit  Metric 

F  ue 1  I n j  ect i on 

adjust 

63D10 

c 

107.  5 

miles 

Cylinder  Head 

repair 

63D20 

c 

1020 

mil  es 

Crankshaft 

repair 

63D20 

c 

980 

m  i  1  es 

Seals,  main 

replace 

Screen  1.58  - 


Component  Maintenance  Parameters  Template  with 
report  options  displayed  on  the  menu  bar. 
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Screen  1.62  -  Component  Maintenance  Parameter  Template  with 
a  discrepancy  cell  highlighted. 

From  this  screen,  the  user  can  either  move  on  to  Step  4 
and  resolve  the  discrepancy  or  review  the  next 
discrepancy. 

User  Actions; 

<ENTER>  -  If  a  discrepancy  still  exists  between  the 
government  and  contractor  estimates  for  this  cell, 
screen  1.63  displays  (Step  4).  If  a  discrepancy  no 
longer  exists,  pressing  the  <ENTER>  key  moves  the  cell 
cursor  to  the  next  identified  discrepancy. 


<ESC>  Returns  the  user  to  screen  1.58. 


PftTH:  MDft>  MMftfi)  Cornporient  Maintenance  Parernetens 


MODE:  Work 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
Act  ion 

MOS/Skill 

Type 

<P/C) 

MOUBF 

Operat ional 
Unit  Metric 

Fuel  Injection 

adjust 

&3D10 

c 

107.  5 

mil  es 

adjust 

63D20 

Cylinder  Head 

repair 

63DS0 

c 

O 

OJ 

miles 

Crankshaft 

repair 

63020 

c 

960 

miles 

Seals,  main 

replace 

— 

Component  Maintenance  Parameter  Template  with  a 
discrepancy  cell  highlighted. 
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Screen  1.66  -  Component  Maintenance  Parameter  Template  with 
report  options  displayed  on  the  menu  bar  and 
the  "PRINTING"  message  displayed. 

From  this  screen,  the  user  must  wait  for  the  printing 
operation  to  complete. 

User  Actions; 

None.  Next  screen  is  1.66A. 
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PATH:  MDA>  MMAA>  Component  Maintenance  Parerneters  MODE:  Wait 

Review  Print  out 

Print  out  a  list  of  discrepancies  by  component 


System  name:  UH-SO  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
ftct i on 

MOS/Skill 

Type 

<P/C) 

MOUBF 

Operat ional 
Unit  Metric 

Fuel  Injection 

adjust 

63D10 

C 

107.  5 

mil  es 

adjust 

PRINTING 

Cylinder  Head 

repair 

c 

1 0£0 

mi  les 

Crankshaft 

repair 

63D£0 

C 

980 

mil  es 

Seals,  main 

replace 

— 

Screen  1.66  -  Component  Maintenance  Parameter  Template  with 
report  options  displayed  on  the  menu  bar  and  the 
"PRINTING"  message  displayed. 
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Screen  1.66A  -  Component  Maintenance  Parameter  Template  with 
report  options  displayed  on  the  menu  bar  and 
the  "PRINTING  COMPLETE"  message  displayed. 

User  Actions; 

The  only  accepted  user  action  is  pressing  the  <ENTER> 
key.  Next  screen  is  1.58. 


PftTH:  MDft>  MMAft>  Component  Maintenance  Parerneters  MODE:  Work 

Review  Print  out 

Print  out  a  list  of  discrepancies  by  component 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
Pet  ion 

MOS/Skill 

Type 

<P/C) 

MOUBF 

Operational 
Unit  Metric 

Fuel  Injection 

ad j  ust 

63D10 

C 

107.  5 

mil  es 

adjust 

PRINTING  COMPLETED 

Press  <ENTER>  to  continue 

■1 

Cylinder  Head 

repair 

loao 

m  i  1  es 

_ 

_ 

Crankshaft 

repair 

63D£0 

C 

980 

miles 

. . ■- . - . . . 

Seals,  main 

_ _ _ _ _ _ _ _ i 

replace 

— 

_ _  _ _ _ _ _ 

Screen  1.66A  -  Component  Mainteiance  Parameter  Template  with 
report  options  displayed  on  the  msdu  bar  and  the 
"PRINTING  COMPLETE"  message  displayed. 
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3.5.4  STEP  4  -  Resolve  the  discrupancies  between  the  government 
baseline  estimates  and  the  contractor’s  design 
estimates  of  the  Component  Maintenance  Parameters. 

3 . 5 . 4 . 1  Input 

External ;  The  external  inputs  for  resolving  Component 

Maintenance  Parameter  discrepancies  are  the  following: 

o  Maintenance  Subject  Matter  Experts 

o  System  design  documents  including  the  maintenance 

task  analysis 

o  System  design  engineers 

o  Analyst  judgement 


Internal :  The  Component  Maintenance  Parameter  discrepancy 
data  file  created  in  Step  3. 


3 . 5 . 4 . 2  Process 

When  the  MMAA  has  identified  and  stored  discrepancies 
between  government  and  contractor  estimates  of  Component 
Maintenance  Parameters  for  a  particular  Functional  System, 
the  analyst  can  review  each  discrepancy  one  by  one  from  the 
Component  Maintenance  Parameter  Template.  The  MMAA  will 
move  the  cell  cursor  to  the  next  discrepancy.  At  this  time,- 
the  user  of  the  MMAA  can  either  resolve  each  discrepancy  by 
changing  the  baseline  estimate  to  one  that  -he  or  she 
believes  is  a  more  realistic  estmate  based  on  further 
analysis  or  leave  the  baseline  estimate  as  it  is.  When  the 
analyst  is  finished  editing  a  cell  and  presses  the  <ENTER> 
key  to  move  on  to  the  next  discrepancy,  the  MMAA  checks  to 
see  if  there  is  still  a  discrepancy  between  the  two 
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estimates.  If  there  is  still  a  discrepancy,  the  system  will 
display  a  message  to  the  user  asking  if  he  or  she  wants  to 
remove  this  set  of  estimates  from  the  discrepancy  list. 

When  the  Maintenance  Requirements  Simulation  model  is 
executed  (Step  6) ,  the  user  will  be  able  to  choose  to  use 
either  the  government  or  contractor's  estimates  of  Component 
Maintenance  Parameters . 

The  flow  diagrams  of  the  process  of  performing  Step  4 
are  included  on  the  following  page. 
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3 . 5 . 4 . 3  Output 


The  output  of  the  step  is  the  Component  Maintenance 
Parameter  file  that  contains  the  contractor's  estimates  of 
maintenance  parameters  for  each  component  and  the 
government's  best  estimate  of  those  same  maintenance 
parameters. 

3 . 5 . 4 . 4  User  Interface 

The  user  interfaces  that  apply  to  this  step  are 
described  in  detail  on  the  following  pages.  Please  note 
that  all  screens  for  the  MMAA  are  labeled  "Screen  l.X". 

Screen  1.57  -  Component  Maintenance  Parameter  Template  with 
menu  bar  commands  displayed. 

From  this  screen,  the  user  can  select  the  "Report" 
command  to  begin  resolving  discrepancies  identified 
during  the  most  recent  "Sort"  operation  or  choose  any 
of  the  other  menu  bar  commands. 

User  Actions! 

Access  Library  -  Next  screen  is  1.41. 

Paste  -  Next  screen  is  1.48. 

Id  Tolerances  -  Next  screen  is  1.52. 

Sort  -  Next  screen  is  1.55. 

Report  -  Next  screen  is  1.58 

<ESC>  Returns  the  user  to  screen  1.31. 
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PftTH:  MDft> MMAft) Component  Maintenance  Paremeters  MODE:  Work 

Pccess  Library  Paste  Id  Tolerances  Sort  Report 

Report  the  discrepancies  between  contractor  and  government  estimates 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 

Component 

Name 

Maintenance 
Act i on 

MOS/Skill 

Type 

<P/C) 

MOUBF 

Operat ional 

Un i t  Met  r i c 

Fuel  Injection 

adjust 

63D 1 0 

C 

107.  5 

miles 

Cylinder  Head 

repair 

63D£0 

c 

1 0£0 

mi  les 

Crankshaft 

repair 

miles 

Seals,  main 

replace 

i 

Screen  1.57  -  Component  Maintenance  Parameter  Template  with  menu 
bar  commands  displayed. 
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Screen  1.63  -  Component  Maintenance  Parameter  Template  with 
discrepancy  message  displayed. 

From  this  screen,  the  user  can  choose  to  remove  this 
discrepancy  from  the  list  or  leave  it  on  the  list  and 
move  to  the  next  discrepancy. 

User  Actions; 

Y  “  Remove  the  current  discrepancy  from  the  list  and 
move  the  cell  cursor  to  the  next  discrepancy.  Next 
screen  is  1.62. 

N  -  Move  the  cell  cursor  to  the  next  discrepancy  in  the 
list  but  don't  remove  this  discrepancy  from  the  list. 

<ESC>  Returns  the  user  to  screen  1.62  without  moving  on 
to  the  next  discrepancy. 


PATH:  MDA>  MMAA>  Component  Maintenance  Parerneters 


MODE:  Work 


System  name:  UH-60  Black  Hawk  Functional  System:  Engine 


Component 

Marne 


F  ue 1  I n j  ect i on 


Cylinder  Head 


Crankshaft 


Seals,  main 


Screen  1.63  *  Component  Maintenance  Parameter  Template  with 
discrepancy  message  displayed. 
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3.5.5  STEP  5  “  Identify/develop  parameters  for  each  maintenance 
scenario  to  be  analyzed  in  terms  of  maintenance 
manhour  and  headcount  requirements,  system 
reliability,  and  system  availability. 

3 . 5 . 5 . 1  Input 

External :  Mission  requirements  obtained  from  the  System 
Performance  Requirements  Estimation  Aid  (SPREA)  in  Product 
1.  Data  on  mission  requirements  obtained  from  the 
Operational  Mode  Summary/Mission  Profile,  MAA/MADP  results, 
LSA,  and  the  Army's  Sample  Data  Collection  system.  Specific 
external  input  data  will  include: 

o  mission  name 
o  number  of  missions  per  day 

o  mean  mission  duration 

o  deviation  (+  -)  from  mission  mean  time 
o  mean  time  between  missions 

o  deviation  (+  -)  from  mean  time  between  missions 

o  operational  units  per  mission  for  each 

hardware/software  component  in  the  system. 

Internal :  The  internal  input  for  this  step  will  be  the  MMAA 

software,  the  Component  Maintenance  Parameters  data  file, 
the  Mission/ Condition  Set  file,  and  the  judgement  of  the 
Army  analyst.  The  specific  information  that  the  analyst 
will  suppy  includes: 

o  A  scenario  file  name 

The  time  span  for  the  simulation 


o 


o 


Judgement  on  selecting  the  other  (external) 
mission  parameters. 


3 . 5 . 5 . 2  Process 

When  the  analyst  has  modified  the  baseline  estimates  of 
Component  Maintenance  Parameters  to  reflect  the  best 
available  estimates,  he  or  she  will  need  to  define  a 
maintenance  scenario  for  the  maintenance  requirements 
simulation.  The  analyst  will  create  a  maintenance  scenario 
to  be  used  by  the  Maintenance  Requirements  Simulation  model 
by  entering  information  into  fields  of  the  Develop 
Maintenance  Scenario  menu.  When  the  analyst  selects 
"Develop  component  operational  units  per  mission"  from  the 
Develop  Maintenance  Scenario  menu,  a  second  menu  will 
display  a  list  of  the  functional  currently  saved  for  the 
system  under  evaluation.  When  a  functional  system  is 
selected,  the  MMAA  will  display  an  Operational  Units  Per 
Mission  Template  showing  the  names  of  each  component  in  the 
selected  Functional  System  and  the  operational  unit  metric 
for  each  component.  This  information  will  be  obtained  from 
the  Component  Maintenance  Parameters  data  file.  The 
Operational  Units  Per  Mission  Template  will  use  the  same 
editing  functionality  as  the  Component  Maintenance 
Parameters  Template.  The  analyst  will  use  the  editing  and 
keystroke  procedures  to  enter  the  average  number  of 
operational  units  per  mission  for  each  component. 

The  flow  diagrams  of  the  process  of  performing  Step  5 
are  included  on  the  following  pages. 
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MMAA  Step  5 

Page  1  of  2 


ProHuct  5 
Mission/ 
System 
Type. 
Taxonomy 


System 
Displays 
Develop 
Maintenance 
Scenario  Menu 


^Select 
Mission 
Name  Field 


or  Select 
Mission 
Name  ? 


System  Displays 
a  List  of 
Missions  for 
the  Current 
System  Type 


Select  a 
Mission  from 
the  List 
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no 


MAA  Step  5 
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3 . 5 . 5 . 3  Output 


The  output  of  this  step  is  a  Maintenance  Scenario 
Paraiaaeters  data  file  for  each  type  of  mission  required  of 
the  system  design  that  is  being  evaluated.  Each  scenario 
data  file  will  be  used  as  input  for  an  execution  of  the 
Maintenance  Requirements  Simulation  model. 

3 . 5 . 5 . 4  User  Interface 


The  user  interfaces  that  apply  to  this  step  are 
described  in  detail  on  the  following  pages.  Please  note 
that  all  screens  for  the  MMAA  are  labeled  "Screen  l.X". 


Screen  1.68  -  Develop  Maintenance  Scenario  menu. 

The  mission  name  field  of  the  Develop  Maintenance 
Scenario  menu  contains  the  mission  name  that  appears  in 
the  Mission/Condition  Set  file  for  this  evaluation. 

From  this  menu,  the  user  can  select  any  of  the  menu 
options  in  any  order.  However,  the  user  must  enter  the 
"Scenario  file  name:"  before  attempting  to  save  the 
maintenance  scenario  data.  All  of  the  fields  on  the 
Develop  Maintenance  Scenario  menu  must  be  completed 
before  the  Maintenance  Requirements  Simulation  model 
can  be  executed. 

User  Actions; 

1.  Mission  name:  -  When  this  option  is  selected  the 
user  is  given  the  opportunity  to  either  "type-in" 
or  "select"  a  new  mission  name.  Next  screen  is 
1.69. 

2.  Scenario  file  name;  -  Lets  the  user  choose  to  type 
in  a  new  scenario  file  name  or  select  an  existing 
scenario  file  to  modify.  Next  screen  is  1.70. 

3.  Simulation  time  span;  -  Displays  a  flashing  cursor 
in  the  field  so  that  the  analyst  can  enter  a 
number  of  days  to  simulate  the  maintenance 
requriements .  Next  screen  is  1.72. 

4.  Number  of  missions  per  day:  -  Displays  a  flashing 
cursor  in  the  field  and  waits  for  analyst  i-nput. 
Next  screen  is  1.73. 

5.  Mission  duration  mean  time:  -  Displays  a  flashing 
cursor  in  the  field  and  waits  for  analyst  input. 
Next  screen  is  1.74. 
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6.  Mission  duration  deviation  (+  -) ;  -  Displays  a 
flashing  cursor  in  the  field  and  waits  for  analyst 
input.  Next  screen  is  1.75. 

7.  Time  between  missions:  -  Displays  a  flashing 
cursor  in  the  field  and  waits  for  analyst  input. 
Next  screen  is  1.76. 

8.  Time  between  missions  (+  -  dev):  -  Displays  a 
flashing  cursor  in  the  field  and  waits  for  analyst 
input.  Next  screen  is  1.77. 

9.  Develop  component  operational  units  per  mission  - 
Displays  a  list  of  the  Functional  Systems 
currently  developed  for  this  system.  Next  screen 
is  1.78. 

<ESC>  Returns  the  user  to  screen  1.1.  If  the  user  has 
changed  any  information  in  any  field  of  the  Develop 
Maintenance  Scenario  menu  since  the  last  time  the  file 
was  saved,  a  warning  message  will  display. 

Output  Files: 

All  maintenance  scenario  information  will  be  written  to 
the  Scenario  file  name  shown  on  the  Develop  Maintenance 
Scenario  menu.  If  the  Scenario  file  name  field  is 
blank,  an  error  message  will  prompt  the  user  to  enter  a 
valid  file  name. 
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PATH:  MDft> MMftP) Develop  Mission  Scenario 


MODE 


► 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troops 
£.  Scenario  file  name: 

3.  Simulation  time  span  (days): 

4.  Number  of  missions  per  day: 

5.  Mission  duration  mean  time  (hours): 

6.  Mission  duration  deviation  (+  -) : 

7.  Time  between  missions  (mean): 

a.  Time  between  missions  (+  -  dev): 

9.  Develop  component  operational  units  pev^  mission 


Screen  1.68  -  Develop  Maintenance  Scenario  menu. 


I 

3-230 


Screen  1.69 


Develop  Maintenance  Scenario  menu  with 
Mission  name  field  highlighted  and  the 
"type-in"  and  "select"  commands  displayed. 

From  this  screen,  the  user  can  choose  to  type-in  a  new 
Mission  name  or  to  select  a  Mission  name  from  a  list  of 
missions  for  the  current  System  Type. 

User  Actions; 

type-in  Displays  a  flashing  cursor  in  the  Mission 
name  field.  Next  screen  is  69B??. 

select  Displays  a  list  of  missions  for  the  current 
System  Type  for  the  user  to  choose  from. 

Next  screen  is  69A??. 

<ESC>  Returns  the  user  to  screen  1.68. 
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PATH:  MDft> MMAA> Develop  Miseion  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troops 
£.  Scenario  file  name: 

3.  Simulation  time  span  (days): 

4.  Number  of  missions  per  day: 

5«  Mission  duration  mean  time  (hours): 

6.  Mission  duration  deviation  (+  —) : 

7.  Time  between  missions  (mean): 

8-  Time  between  missions  (+  —  dev): 

9.  Develop  component  operational  units  per  mission 


type-in  select. 


Screen  1.69  - 


Develop  Maintenance  Scenario  menu  with  Mission 
name  fieid  highiighted  and  the  "type-in"  and 
"seiect"  commands  displayed. 
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Screen  1.69B  -  Develop  Maintenance  Scenario  menu  with  a 

flashing  cursor  displayed  in  the  Mission  name 
field. 

From  this  screen,  the  user  can  type-in  a  new  mission 
name  for  this  scenario. 

User  Actions! 

Using  normal  editing  keys  and  procedures,  the  user  will 
enter  a  mission  name.  Input  will  be  terminated  by 
pressing  the  <ENTER>  key.  Next  screen  is  1.68. 


<ESC>  Returns  the  user  to  screen  1.69. 


PATH:  MDA> MMAA> Devel op  Mission  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  nanie:_^ 

2.  Scenario  file  name: 

3.  Simulation  time  span  (days): 

4.  Number  of  missions  per  day: 

5-  Mission  duration  mean  time  (hours): 

6.  Mission  duration  deviation  (+  -) : 

7-  Time  between  missions  (mean): 
a.  Time  between  missions  (+  ~  dev): 

9.  Develop  component  operational  units  per  mission 


type-in  select 


Screen  1.69B  -  Develop  Maintenance  Scenario  menu  with  a  flashing 
cursor  displayed  in  the  Mission  name  fieid.  . 
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L 


Screen  1.69A  -  List  of  Missions  for  the  current  System  Type. 

From  this  screen,  the  user  can  select  a  mission  name 
for  this  scenario. 

User  Actions: 

Using  normal  menu  selection  procedures,  the  user  will 
select  a  mission  name.  Next  screen  is  1.68. 

<ESC>  Returns  the  user  to  screen  1.69. 


Input  Files; 

Product  5  Missions  by  System  Type  Taxonomy  file. 


MDfl> MMftft) Develop  Mission  Scenario 


MODE:  Work 


DE'^ELOP  MflINT 

I 

UTILITY  HELICOPTER  MISSIONS 

1.  Mission  name: 

1.  Transport  Combat  Troops 

2.  Scenario  file  name: 

2.  Transport  Logistical  Supplies 

3.  Simulation  time  span 

3-  Evacuate  Casualties 

4,  Number  of  missions  pe 

5. 

5-  Mission  duration  mean 

6- 

6.  Mission  duration  devi 

7. 

7  T*  1  nm  lAiaovt  mi  esc  i  i— iv**o 

f  m  1  X  iiic?  LJ IS  1/ tz?  r  1  lit  X  A X  r  1 9 

a.  Time  between  missions 

(+  -  dev) : 

' 

9.  Develop  component  operational  units  per  mission 

type-in 

select 

Screen  1.69A  -  List  of  Missions  fot*  the  current  System  Type 


Screen  1.70 


-  Develop  Maintenance  Scenario  menu  with 
'•Scenario  file  name;"  highlighted  and  the 
"type-in"  and  "select"  commands  displayed. 

From  this  screen,  the  user  can  choose  to  either  type-in 
a  new  file  name  for  this  scenario  or  select  an  already 
existing  scenario  file  to  modify. 

User  Actions; 

type-in  A  flashing  cursor  displays  in  the  "Scenario 
file  name"  field.  Next  screen  is  1.70A??. 

select  A  list  of  Scenario  files  that  have  been  saved 
for  the  identified  System  Type  displays. 

Next  screen  is  1.71. 

<ESC>  Returns  the  user  to  screen  1.68. 
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PftTH:  MDft> MM AP> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MftlNTENANCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troops 
S«  Scenario  file  name: 

3.  Simulation  time  span  <days) : 

4-  Number  of  missions  per  day: 

5,  Mission  duration  mean  time  (hours): 

6,  Mission  duration  deviation  (+  -) : 

7.  Time  between  missions  (mean): 

8.  Time  between  missions  (h-  -  dev): 

9«  Develop  component  operational  units  per  mission 


type-in  select 


Screen  1.70  -  Develop  Maintenance  Scenario  menu  with  "Scenario 
file  name:"  highllghled  and  the  "type-ln"  and 
"select"  commands  displayed. 
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Screen  1.70A  -  Develop  Maintenance  Scenario  menu  with 

flashing  cursor  displayed  in  the  "Scenario 
file  name"  field. 

From  this  screen,  the  user  can  type-in  a  new 
Maintenance  Scenario  file  name  for  this  scenario. 

User  Action! 

Using  normal  editing  keys  and  procedures,  the  user  will 
enter  a  scenario  file  name.  Input  will  be  terminated 
by  pressing  the  <ENTER>  key.  Next  screen  is  1.68. 


<ESC>  Returns  the  user  to  screen  1.70. 


PTH:  MDft> MMAA> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  name;  Transport  Combat  Tv'oops 
£.  Scenario  file  name;  _ 

3-  Simulation  time  span  (days); 

4.  Number  of  missions  per  day: 

5.  Mission  duration  mean  time  (hours); 

6-  Mission  duration  deviation  (+  -) : 

7.  Time  between  missions  (mean): 

Qm  Time  between  missions  (+  -  dev); 

9.  Develop  component  operational  units  per  mission 


type-in  select 


Screen  1.70A  -  Develop  Maintenance  Scenario  menu  with  flashing 
cursor  displayed  in  the  "Scenario  file  name" 
field. 
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Screen  1.71  -  List  of  Maintenance  Scenario  files  for  the 
current  System  Type. 

From  this  screen,  the  user  can  select,  copy,  or  delete 

a  scenario  file. 

User  Actions: 

select  The  MMAA  software  reads  the  highlighted 
scenario  file  and  displays  the  field 
parameters  on  the  Develop  Maintenance 
Parameters  menu.  Next  screen  is  1.72. 

copy  When  the  copy  command  is  chosen  the  user  can 

make  an  exact  copy  of  an  existing  Maintenance 
Scenario  file.  The  system  displays  a 
flashing  cursor  in  a  blank  field  directly 
below  the  highlighted  file  name.  Next  screen 
is  1.71A. 

delete  When  the  delete  command  is  chosen,  the  user 
can  delete  the  highlighted  Maintenance 
Scenario  file  from  the  list.  The  system 
displays  a  delete  verification  message  before 
actually  deleting  the  file.  Next  screen  is 
1.71B. 

<ESC>  Returns  the  user  to  screen  1.70. 


Maintenance  Scenario  files  for  the  current  System  Type. 
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PftTH:  MDA> MMAA> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MftINTENPNCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troo 
£•  Scenario  file  name; 

3.  Simulation  time  span  (days): 

4.  Number  of  missions  per  day: 

5.  Mission  duration  mean  time  (hours): 

6.  Mission  duration  deviation  (+  -“)  : 

7.  Time  between  missions  (mean): 

8.  Time  between  missions  (+  —  dev): 


9.  Develop  component  operational  units 


SCENARIO  FILES  FOR: 
UTILITY  HELICOPTER 


1. 

TRANSOl 

£« 

TRANSOS 

3. 

RECONOl 

select 

copy  delete 

t  ype-^in 


select 


Screen  1.71  - 


List  of  Maintenance  Scenario  files  for  the  current 
System  Type. 
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Screen  1.71A  -  List  of  Maintenance  Scenario  files  with  a 
flashing  cursor  displayed  in  a  blank  field 
directly  below  the  file  to  be  copied. 

User  Actions; 

The  system  will  wait  for  the  user  to  enter  a  string  of 
allowable  characters  to  be  used  as  the  name  of  the  new 
copy  of  the  highlighted  file.  The  user  will  terminate 
the  string  by  pressing  the  <ENTER>  key.  The  file  name 
must  begin  with  an  alpha  character  and  can  contain  up 
to  eight  alpha,  numeric,  underscore,  and  hyphen 
characters.  All  characters  beyond  the  first  eight  will 
be  truncated.  If  the  file  name  entered  contains  any 
characters  that  are  not  allowed,  a  tone  will  sound  and 
an  error  message  will  display.  Next  screen  is  1.71. 

<ESC>  Returns  the  user  to  screen  1.71. 


Input  Files; 


Maintenance  Scenario  files  for  the  current  System  Type. 


PATH:  MDA> MMftA) Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troo 
S.  Scenario  file  name: 

3.  Simulation  time  span  (days): 

4.  Number  of  missions  per  day: 

5.  Mission  duration  mean  time  (hours): 
6-  Mission  duration  deviation  (+  -) : 

7.  Time  between  missions  (mean) : 

8.  Time  between  missions  (+  -  dev): 

3m  Develop  component  operational  units 


SCENfiRIO  FILES  FOR: 
UTILITY  HELICOPTER 

1. 

TRftNSOl 

a. 

3- 

TRfiNSOa 

4. 

RECONOl 

select 

copy  delete 

type-in 


select 


Screen  1.71A  -  List  of  Maintenanco  Scenario  files  with  a  flashing 
cursor  displayed  in  a  blank  field  directly  below 
the  file  to  be  copi(  ci. 
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Screen  1.71B  -  Verification  message  for  deleting  a  scenario 
file. 

To  avoid  accidental  deletion  of  a  scenario  file,  the 

delete  operation  must  be  verified  by  the  user. 

User  Actions; 

Y  The  system  deletes  the  highlighted  file  name  on 
the  list  of  scenario  files.  Next  screen  is  1.71. 

N  The  delete  command  is  cancelled.  Returns  the  user 
to  screen  1.71  without  performing  the  delete 
operation. 

<ESC>  Returns  the  user  to  screen  1.71  without 

performing  the  delete  operation.  Pressing  the  <ESC> 

key  is  functionally  the  same  as  pressing  "N” . 

Input  Files: 

Maintenance  Scenario  files  for  the  current  System  Type. 


Screen  1.71B  -  Verification  messay;?  for  deieting  a  scenario  file. 
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Screen  1.72  -  Develop  Maintenance  Scenario  file  with  a 

flashing  cursor  displayed  in  the  "Simulation 
time  span"  field. 

From  this  screen,  the  user  can  enter  the  number  of  days 
to  simulate  maintenance  requirements. 

User  Actions; 

The  user  will  use  numeric  keys  to  enter  the  number  of 
days  for  the  simulation.  Next  screen  is  1.68  with  the 
niimber  of  days  displayed. 

<ESC>  Returns  the  user  to  screen  1.68  without  changing 
the  simulation  time  span. 


PATH:  MDA> MMAA> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troops 
S.  Scenario  file  name:  TRANSOl 
3m  Simulation  time  span  (days):  ^ 

4-  Number  of  missions  per  day: 

5.  Mission  duration  mean  time  (hours): 

6.  Mission  duration  deviation  (+  -) : 

7-  Time  between  missions  (mean): 

a.  Time  between  missions  (+  -  dev): 

9.  Develop  component  operational  units  per  mission 


Screen  1.72  -  Develop  MaintenanDe  Scenario  file  with  a  flashing 
cursor  displayed  in  the  "Simulation  time  span" 
field. 


Screen  1.73  -  Develop  Maintenance  Scenario  file  with  a 

flashing  cursor  displayed  in  the  "Number  of 
missions  per  day"  field. 

From  this  screen,  the  user  can  enter  the  expected 
number  of  missions  per  day  in  order  to  simulate 
maintenance  requirements . 

User  Actions; 

The  user  will  use  numeric  keys  to  enter  the  number  of 
missions  per  day  for  the  simulation.  Next  screen  is 
1.68  with  the  number  of  missions  per  day  displayed. 

<ESC>  Returns  the  user  to  screen  1.68  without  changing 
the  number  of  missions  per  day  field. 


PftTH:  MDP> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MPINTENPNCE  SCENARIO 


Im  Mission  name:  Transport  Combat  Troops 
£.  Scenario  file  name:  TRANSOl 
3-  Simulation  time  span  <days) :  365 
4.  Number  of  missions  per  day: 

5-  Mission  duration  mean  time  (hours): 

6-  Mission  duration  deviation  (*+*  -)  : 

7.  Time  between  missions  (mean): 

8-  Time  between  missions  (+  -  dev): 

9-  Develop  component  operational  units  per  mission 


Screen  1.73  -  Develop  Maintenance  Scenario  file  with  a  flashing 
cursor  displayed  in  the  "Number  of  missions  per 
day"  field. 

I 

I 
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Screen  1.74 


Develop  Maintenance  Scenario  file  with  a 
flashing  cursor  displayed  in  the  "Mission 
duration  jmean  time"  field. 

From  this  screen,  the  user  can  enter  the  mean  duration 
of  one  of  the  identified  a  missions. 

User  Actions! 

The  user  will  use  numeric  keys  to  enter  the  Mission 
duration  mean  time.  Next  screen  is  1.68  with  the 
mission  duration  mean  time  displayed. 

<ESC>  Returns  the  user  to  screen  1.68  without  changing 
the  mission  duration  mean  time. 
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PATH:  MDA> MMAA> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MftINTENfiNCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troops 
£•  Scenario  file  name:  TRANSOl 
3m  Simulation  time  span  (days):  365 
4-  Number  of  missions  per  day:  6 

5.  Mission  duration  mean  time  (hours)  : _ 

6.  Mission  duration  deviation  (+  -~)  : 

7-  Time  between  missions  (mean): 

&m  Time  between  missions  (+  --  dev): 

9.  Develop  component  operational  units  per  mission 


Screen  1.74  - 


Develop  Maintenance  Scenario  file  with  a  flashing' 
cursor  displayed  in  the  "Mission  duration  mean 
time"  field. 
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Screen  1.75  -  Develop  Maintenance  Scenario  file  with  a 
flashing  cursor  displayed  in  the  "Mission 
duration  deviation"  field. 

From  this  screen,  the  user  can  enter  the  expected 
amount  of  deviation  from  the  mean  for  mission  length. 

User  Actions; 

The  user  will  use  numeric  keys  to  enter  the  deviation 
amount.  Next  screen  is  1.68  with  the  mission  duration 
deviation  displayed. 

<ESC>  Returns  the  user  to  screen  1.68  without  changing 
the  mission  duration  deviation. 
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PATH:  MDA> MMAA> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troops 
£-  Scenario  file  name:  TRANSOl 
3-  Simulation  time  span  (days):  365 

4.  Number  of  missions  per  day:  6 

5.  Mission  duration  mean  time  (hours):  S 

6.  Mission  duration  deviation  (+  -) :  _ 

7.  Time  between  missions  (mean): 

a.  Time  between  missions  (+  -  dev): 

9-  Develop  component  operational  units  per  mission 


Screen  1.75  - 


Develop  Maintenance  Scenario  file  with  a  flashing 
cursor  displayed  in  the  "Mission  duration 
deviation"  field. 
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Screen  1.76  -  Develop  Maintenance  Scenario  file  with  a 
flashing  cursor  displayed  in  the  "Time 
between  missions  (mean)"  field. 

From  this  screen,  the  user  can  enter  the  mean  number  of 
hours  between  missions. 

User  Actions: 

The  user  will  use  n\americ  keys  to  enter  the  mean  number 
of  hours  between  missions  for  the  simulation.  Next 
screen  is  1.68  with  the  mean  number  of  hours  between 
missions  displayed. 

<ESC>  Returns  the  user  to  screen  1.68  without  changing 
the  mean  number  of  hours  between  missions. 


PftTH:  MDft> Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


!•  Mission  name:  Transport  Combat  Troops 
2-  Scenario  file  name:  TRANSOl 

3.  Simulation  time  span  (days):  365 

4.  Number  of  missions  per  day:  6 

5.  Mission  duration  mean  time  (hours):  2 

6.  Mission  duration  deviation  (+  -) :  .5 

7.  Time  between  missions  (mean):  — ^ 

8.  Time  between  missions  (+  —  dev) : 

9«  Develop  component  operational  units  per  mission 


Screen  1.76  -  Develop  Maintenance  Scenario  file  with  a  flashing 
cursor  displayed  in  the  "Time  between  missions 
(mean)"  field. 
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Screen  1.77  -  Develop  Maintenance  Scenario  file  with  a 
flashing  cursor  displayed  in  the  "Time 
between  missions  (+  -  dev)"  field. 

From  this  screen,  the  user  can  enter  the  expected  +  or 
-  deviation  from  the  mean  time  between  missions. 

User  Actions! 

The  user  will  use  numeric  keys  to  enter  the  time 
between  missions  deviation  the  simulation.  Next  screen 
is  1.68  with  the  +  -  deviation  of  mean  time  between 
missions  displayed. 

<ESC>  Returns  the  user  to  screen  1.68  without  changing 
the  deviation  of  time  between  missions. 
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PATH:  MDP> MMftP) Develop  Mission  Scenario 


MODE:  Work 


DEVELOP  MAINTENANCE  SCENARIO 


1.  Mission  name:  Transport  Combat  Troops 
£.  Scenario  file  name:  TRANSOl 

3.  Simulation  time  span  <days) :  365 

4.  Number  of  missions  per  day:  6 

5.  Mission  duration  mean  time  (hours):  £ 

6.  Mission  duration  deviation  (+  -) :  .5 

7.  Time  between  missions  (mean):  2 

8.  Time  between  missions  (+  -  dev):  — 

S.  Develop  component  operational  units  per  mission 


Screen  1.77  -  Develop  Maintenance  Scenario  file  with  a  flashing 
cursor  displayed  in  the  "Time  between  missions  (+ 
-  dev)"  field. 
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Screen  1.78  -  Current  List  of  Functional  Systems  for  the 
system  under  eveluation. 

From  this  screen,  the  user  can  select  a  Functional 
System  for  which  he  or  she  will  enter  the  number  of 
operational  units  that  will  be  attributed  to  each 
component  for  each  mission. 

User  Actions! 

Using  normal  menu  selection  procedures,  the  user  will 
select  a  functional  system.  Next  screen  is  1.79. 

<ESC>  Returns  the  user  to  screen  1.68. 
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PftTHs  MDft> MMAfl> Develop  Mission  Scenario 


MODE:  Work 


CURRENT 

LIST  OF  FUNCTIONAL  SYSTEMS 

1. 

Hydraul ics  System 

£. 

Electrical  System 

3. 

Communicat ion  System 

4. 

Engine 

select 

Screen  1.78  - 


Current  List  of  Functional  Systems  for  the  system 
under  eveluation. 


Screen  1.79  -  Operational  Units  Per  Mission  Template  with 
the  name  and  operational  unit  metric 
displayed  for  each  component  in  the 
Functional  System. 

User  Actions; 

From  this  screen,  the  user  can  use  normal  template 
editing  keys  and  procedures  to  enter  the  number  of 
operational  units  per  mission  for  each  component  in  the 
Functional  system.  Next  screen  is  1.68. 


<ESC>  Returns  the  user  to  screen  1.68. 


PATH:  MDfl> MMAA) Develop  Mission  Scenario 


MODE;  Wor 


OPERATIONAL  UNITS  PER  MISSION 

System  Name:  UH-60  Black  HaMk 

Functional  System:  Engine 

Component  Name 

Operational  Unit 
Metric 

<>i,  rounds,  miles) 

Operat ional 
Units/Mission 

Fuel  Injection 

m  i  1  es 

75 

Cylinder  Head 

miles 

75 

Crank  Shaft 

mi  les 

75 

Seals,  main 

mil  es 

Master  Cylinder 

mi  les 

Battery  Pack 

%  of  mission  time 

Screen  1.79  -  Operational  Units  t’er  Mission  Template  with  the 
name  and  operational  unit  metric  displayed  for 
each  component  in  the  Functional  System. 
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3.5.6  STEP  6  -  Run  the  Maintenance  Requirements  Simulation  model 
to  calculate  manhour  and  headcount  requirements, 
system  reliability,  and  system  availability  for 
each  maintenance  scenario. 

3 . 5 . 6 . 1  Input 
External !  None 

Internal ;  The  Component  Maintenance  Parameter  file 
developed  in  Steps  1-4,  the  Maintenance  Scenario  file 
developed  in  Step  5,  and  the  Maintenance  Requirements 
Simulation  model  that  is  embedded  within  the  MMAA. 

3 . 5 . 6 . 2  Process 

When  all  of  the  Component  Maintenance  Parameters  and 
Maintenance  Scenario  parameters  have  been  identified  for  all 
of  the  Functional  Systems  under  evaluation,  the  analyst  can 
execute  the  Maintenance  Requirements  Simulation  model.  For 
each  execution  of  the  model,  the  analyst  will  be  able  to 
specify  the  System  Name,  the  Maintenance  Scenario  file  name, 
and  whether  to  use  government  or  contractor  estimates  for 
the  simulation. 

If  any  of  the  required  input  from  the  Component 
Maintenance  Paraemeter  or  Maintenance  Scenario  data  files  is 
missing,  incomplete  or  in  error,  the  MMAA  software  will 
issue  an  error  message  and,  if  possible,  execution  will 
continue.  If  a  fatal  error  is  encountered,  the  execution 
will  terminate.  Each  error  message  that. is  encountered  will 
be  written  to  an  errors  file  for  the  current  system  and 
scenario  name.  The  errors  file  can  be  viewed  and/or  printed 
out  from  the  MDA  Utilities  Application. 


The  flow  diagram  of  the  process  of  performing  Step  6 
are  included  on  the  following  page. 
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MMAA  Step  6 


Proouct 

5 

System 

File 

Names 


System  Displays 
Execute 

Maintenance  ~ 
Simulation  Menu 


Change  \  yes 
System  Name  V- — 
?  / 


Select 
System  Name 
Field 


System  Displays 
List  of  System 
Names  Currently 
Developed 


Select  a 
System  Name 
from  the  List 


Product  5 
Scenario 
Files 


Change  N. 

Mission  N.  yes 
Scenario  Filey-^ — 

V  ?  X 


^Select 
Mi  ssion 
Scenario  File 
Name  Field 


System  Displays 
List  of 

Scenario  Files 
for  Current 
System 


Select  a 
Scenario  File 
from  the  List 


X  Govt.  % 
or 

Contractor 
Estimates , 
V  ?  y 


Select  Comp. 
Param.  Est,., 
to  be  Used" 
Field 
(toggle) 


y  Execute 
Simulation 
More  than 
Once  ? 


„  Select 
Numj^er  of 
Runs  Field 


«  Enter  ■ 

the 

Number 

of 

Times  to 

Run 

the 

Simulat 

ion  ^ 

System  Displays 
In  Progress 
Message.  Wait 
for  Completion. 


3 . 5 . 6 . 3  Output 


The  output  of  the  Maintenance  Requirements  Simulation 
model  execution  is  the  creation  of  two  Simulation  Results 
data  files.  The  Maintenance  Manpower  Requirements  file 


contains 

maintenance  manhours  by: 

o 

maintenance  action 

o 

component 

o 

MOS/Skill  Level 

o 

maintenance  level  (org,  ds,  gs) 

o 

maintenance  type 

The  Maintenance  Manpower  Requirements  file  also 
contains  an  estimate  of  the  maintenance  headcount 
requirements . 

The  Mission  Completion  data  file  contains  the 
following  information: 

o  Missions  started 

o  Missions  completed 

o  Missions  missed 

o  Missions  aborted 


3. 5. 6. 4  User  Interface 


The  user  interfaces  that  apply  to  this  step  are 
described  in  detail  on  the  following  pages.  Please  note 
that  all  screens  for  the  MMAA  are  labeled  ’’Screen  l.X”. 
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Screen  1.81  -  Execute  Maintenance  Simulation  menu. 

From  this  screen,  the  user  can  identify  a  system  name 
for  the  model  execution,  select  a  Maintenance  scenario 
file  name,  and  choose  to  use  government  or  contractor 
estimates  to  run  the  simulation  model.  The  Execute 
Maintenance  Simulation  menu  will  display  as  defaults 
the  currently  identified  System  Name  and  Maintenance 
Scenario  file.  However,  the  user  may  execute  the 
simulation  for  any  System  Name  and  Maintenance  Scenario 
file  that  resides  on  the  disk. 

User  Actions; • 

1.  System  Name  -  Lets  the  user  choose  to  "type-in”  or 
"select"  a  new  System  Name  for  the  simulation. 

Next  screen  is  1.81A.  If  the  System  Name  that  the 
user  enters  is  not  on  the  working  disk,  an  error 
message  will  display. 

2.  Maintenance  Scenario  file  name  -  Lets  the  user 
choose  to  "type-in"  or  "select"  a  new  Maintenance 
Scenario  file  for  the  next  simulation.  Next 
screen  is  1.82.  If  the  System  Name  that  the  user 
enters  is  not  on  the  working  disk,  an  error 
message  will  display. 

3.  Component  Maintenance  Parameter  estimates  to  be 
used  -  Lets  the  user  toggle  between  using 
government  and  contractor  design  estimates  for  the' 
next  simulation.  Next  screen  is  1.85. 

4.  GO  -  Begins  execution  of  the.  Maintenance 
Requirements  Simulation  Model.  Next  screen  1.86. 

<ESC>  Returns  the  user  to  screen  1.1. 
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PATH:  MDA> MMAA> Execute  Maintenance  Simulation 


MODE:  Work 


EXECUTE  MAINTENANCE  SIMULATION 


1.  System  Name:  UH-SO  Black  Hawk 
S-  Mission  Scenario  file  name:  TRANSOi 
3-  Component  parameter  estimates  to  be  used:  govt, 
4,  GO 


Screen  1.81  - 


Execute  Maintenance;  Simulation  menu. 
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Screen  1.81A  -  Execute  Maintenance  Simulation  menu  with  the 
"System  Name"  field  highlighted  and  the 
"type-in"  and  "select"  commands  displayed. 

From  this  screen,  the  user  can  choose  to  type-in  a  new 
System  Name  for  the  next  simulation  execution  or  select 
from  a  list  of  system  names  currently  stored  on  the 
disk. 

User  Actions; 

type-in  A  flashing  cursor  will  display  in  a  blank 
System  name  field.  Next  screen  is  1.81B. 

select  A  list  of  System  Names  whose  files  are  stored 
on  the  current  working  disk  is  displayed. 

Next  screen  is  1.8 1C. 

<ESC>  Returns  the  user  to  screen  1.81. 
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PATH!  MDA>  MMftA>  Execute  Mairttenance  Simulation 


MODE:  Work 


EXECUTE  MAINTENANCE  SIMULATION 


1.  System  Name:  UH-60  Black  Hawk 

2.  Mission  Scenario  file  name:  TRANSOl 

3.  Component  parameter  estimates  to  be  used:  govt. 

4.  GO 


type-in  select 


Screen  1.81  A  -  Execute  Maintenance  Simulation  menu  with  the 
"System  Name"  field  highlighted  and  the  "type-in" 
and  "select"  comma;  is  displayed. 
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Screen  1.81B  -  Execute  Maintenance  Simulation  menu  with  a 

flashing  cursor  displayed  in  the  System  Name 
field. 

User  Actions; 

Using  norman  editing  keys  and  procedures,  the  user  will 
enter  a  System  Name.  Next  screen  is  1.81.  If  the 
System  Name  that  the  user  enters  does  not  reside  on  the 
current  working  disk,  an  error  message  will  display. 

<ESC>  Returns  the  user  to  screen  1.81. 
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PfiTH;  MDft> MMftfi) Execute  Ma i nt enance  Simulation 


MODE:  Work 


EXECUTE  MfilNTENftNCE  SIMULATION 


1.  System  Name:  — 

2.  Mission  Scenario  file  name:  TRANSOl 

3.  Component  parameter  estimates  to  be  used:  govt. 

4.  60 


type-in  select 


Screen  1.81  B  - 


Execute  Maintenance  Simulation  menu  with  a 
flashing  cursor  dispiayed  in  the  System  Name 
fieid. 
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Screen  1.8 1C  -  List  of  System  Names  whose  files  are  saved  on 
the  current  working  disk. 

User  Actions; 

Using  normal  menu  selection  procedures,  the  user  will 
select  a  System  Name  from  the  list.  Next  screen  is 
1.81. 


<ESC>  Returns  the  user  to  screen  1.81. 


PftTH;  MDfl> MMftA> Execute  Maintenance  Simulation 


MODE:  Work 


EXECUTE  MAINTENANCE  SIMULATIO 

1 

CURRENT  SYSTEM  NAMES 

1.  System  Name: 

£.  Mission  Scenario  file  name:  TRANSOl 

3.  Component  parameter  estimates  to  be 

4.  SO 

1.  UN-60  Black  Hawk 

2.  UH-1  Iroquois 

3.  AH— 1  Apache 

4.  AH-IS  Cobra 

5.  M60  Tank 

type-in  select 

Screen  1.81C  - 


List  of  System  Nam  os  whose  files  are  saved  on  the 
current  working  disk. 
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Screen  1.82  -  Execute  Maintenance  Simulation  menu  with  the 
•'Maintenance  Scenario  file  name"  field 
highlighted  and  the  "type-in"  and  "select" 
commands  displayed. 

From  this  screen,  the  user  can  choose  to  type-in  a  new 
Maintenance  Scenario  file  name  for  the  next  simulation 
execution  or  to  select  a  new  Maintenance  Scenario  file 
for  this  System  Name  from  a  list  of  those  residing  on 
the  current  working  disk. 

User  Actions; 

type-in  A  flashing  cursor  will  display  in  a  blank 

"Maintenance  Scenario  file  name"  field.  Next 
screen  is  1.82A. 

select  A  list  of  Maintenance  Scenario  files  for  the 
current  System  Name  displays.  Next  screen  is 
1.83. 

<ESC>  Returns  the  user  to  screen  1.81. 
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PATH;  MDA> MMAft> Execute  Maintenance  Simulation 


MODE:  Work 


EXECUTE  MAINTENANCE  SIMULATION 


1.  System  Name:  UH-60  Black  Hawk 

2.  Mission  Scenario  file  name:  TRANSOl 

3.  Component  parameter  estimates  to  be  used:  govt. 

4.  GO 


type-in  select 


Screen  1.82  -  Execute  Maintenance  Simulation  menu  with  the 

"Maintenance  Scenario  file  name"  field  highlighted 
and  the  "type-in"  and  "select"  commands  displayed. 
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Screen  1.82A  -  Execute  Maintenance  Simulation  menu  with  the 
"Maintenance  Scenario  file  name"  field 
highlighted  and  a  flashing  cursor  displayed. 

User  Actions; 

Using  normal  editing  keys  and  procedures,  the  user  will 
enter  the  name  of  an  existing  Maintenance  Scenario  file 
to  be  used  for  the  next  simulation  model  execution. 

Next  screen  is  1.81.  If  the  file  name  entered  does  not 
reside  on  the  current  working  disk,  an  error  message 
will  be  displayed. 

<ESC>  Returns  the  user  to  screen  1.81  with  the 
previous  file  name  displayed. 
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PftTH:  MDft>  MMftft)  Execute  Mairitenance  Simulation 


MODE;  Work 


EXECUTE  MfilNTENANCE  SIMULATION 


1.  System  Name:  UH-60  Black  Hawk 

2.  Mission  Scenario  file  name:  ~ 

3.  Component  parameter  estimates  to  be  used:  govt. 

4.  80 


type-in  select 


Screen  1.82A  -  Execute  Maintenance  Simulation  menu  with  the 

"Maintenance  Scenario  file  name"  field  highlighted 
and  a  flashing  cursor  displayed. 
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Screen  1.83  -  List  of  Maintenance  Scenario  files  that  are 

saved  on  the  current  working  diskette  for  the 
identified  System  Name. 

User  Actions; 

Using  normal  menu  selection  procedures,  the  user  will 
select  a  Maintenance  Scenario  file  from  the  list  for 
the  next  simulation  model  execution.  Next  screen  is 
1.81.  If  the  current  working  disk  does  not  contain  any 
Maintenance  Scenario  files  for  the  identified  System 
Name,  a  message  will  display. 

<ESC>  Returns  the  user  to  screen  1.81  with  the 
previous  file  name  displayed  in  the  "Maintenance 
Scenario  file  name"  field. 
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PATH:  MDA>  MMAA>  Execute  Ma  i  rit  enance  Simulation 


MODE;  Work 


1. 

S. 

3. 

4. 


EXECUTE  MAINTENANCE  SIMULATION 


System  Name:  UH-60  Black  Hawk 
Mission  Scenario  file  name:  TRANSOi 
Component  parameter  estimates  to  be  us 
GO 


type— in 


select 


SCENARIO  FILES  FOR; 

UN-60 

BLACK  HAWK 

1. 

TRANSOI 

a. 

TRfiNSOa 

3. 

RECONOl 

Screen  1.83  -  List  of  Maintenance  Scenario  files  that  are  saved 
on  the  current  working  diskette  for  the  identified 
System  Name. 
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Screen  1.85 


Execute  Maintenance  Simulation  menu  with  the 
"Component  parameter  estimates  to  be  used" 
field  highlighted. 

From  this  screen,  the  user  can  toggle  between  using 
government  estimates  of  Component  Maintenance 
Parameters  for  the  next  execution  of  the  simulation 
model  and  using  the  contractor's  design  estimates. 

User  Actions; 

When  this  field  is  highlighted,  each  time  the  user 
presses  the  <ENTER>  key  the  field  entry  toggles  between 
"govt."  arid  "design".  Next  screen  is  1.81. 

<ESC>  Returns  the  user  to  screen  1.1. 
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PATH :  MDA>  MMAft)  Execute  Maint eriance  Sirnulat  ion 


MODE:  Work 


EXECUTE  MAINTENANCE  SIMULATION 


1.  System  Name;  UH-SO  Black  Hawk 
£•  Mission  Scenario  file  name;  TRANSOl 

3.  Component  parameter  estimates  to  be  used:  design 

4.  GO 


Screen  1.85  -  Execute  Maintenance  Simulation  menu  with  the 

"Component  parameter  estimates  to  be  used"  field 
highlighted. 
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Screen  1.86  -  Execute  Maintenance  Simulation  with 

"Simulation  in  Progress"  message  displayed. 

User  Actions: 

None.  Next  screen  1.87. 

Input  Files! 

Component  Maintenance  Parameter  file  and  Maintenance 
Scenario  file  for  the  identified  system. 
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OJ  't 


P^^THs  MDft>  MMPA>  Execute  Maint enance  Sirnulat  ion 


MODE:  Wait 


EXECUTE  MAINTENANCE  SIMULATION 


1.  System  Name:  UH-60  Black  Hawk 
.  Mission  Scenario  file  name:  TRANSOl 
•  Component  parameter  estimates  to  be  used:  govt- 
.  GO 


SIMULATION 
IN  PROGRESS 


Screen  1.86  - 


Execute  Maintenance  Simulation  with  "Simulation  in 
Progress"  message  displayed. 
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Screen  1.87  -  Simulation  Complete  summary  screen. 

This  screen  gives  the  user  a  summary  of  the  simulation 
outcomes . 

User  Actions; 

P  Pressing  this  key  will  cause  the  simulation 

summary  screen  to  be  printed.  Next  screen  is 
1.81. 

<ENTER>  Returns  the  user  to  screen  1.81. 


<ESC>  Returns  the  user  to  screen  1.81. 


MDft>  Execute  Maint enance  Simulation 


3.5.7  STEP  7  -  Analyze  the  results  of  the  Maintenance 

Requirements  Simulation  Model  execution. 

In  terms  of  the  maintenance  jobs  that  are  required,  the 
maintenance  tasks  that  make  up  each  job,  the 
maintenance  manhours  and  headcount  requirements,  system 
availability,  and  system  reliability.  These 
maintenance  requirements  are  then  compared  to  the 
system  performance  requirements  identified  in  the 
Product  1  SPREA  analysis  and  the  Product  2  manpower 
constraints . 

3 . 5 . 7 . 1  Inputs 

External ;  The  System  RAM  Criteria  file  and  the 
Corrective  Maintenance  Criteria  files  that  are  an 
output  of  the  Product  1  SPREA  analysis  and  the 
Maintenance  Manpower  Constraints  and  Source  MOS  Reports 
that  are  an  output  of  the  Prpduct  2  MCEA  analysis. 

Internal ;  The  Maintenance  Manpower  Requirements  file 
and  the  Mission  Completion  files  that  were  produced  as 
an  output  of  the  execution  of  the  Maintenance 
Requirements  Simulation  Model  in  Step  6. 

3. 5. 7. 2  Process 

The  execution  results  of  the  Maintenance  Requirements 
Simulation  Model  are  stored  in  two  data  files  that  will 
serve  as  a  relational  data  base  of  maintenance  requir.ements 
information.  A  maintenance  reports  generator  will! be 
developed  to  allow  the  user  to  obtain,  combine,  and  display 
or  print  information  from  the  results  data  files  in 
different  ways. 


The  reports  generator  will  produce  two  basic  types  of 
reports  automatically  that  the  analyst  will  use  to  determine 
the  overall  maintenance  requirements  for  the  system  design. 
The  first  is  a  Maintenance  Manhour  Requirements  report. 

This  report  is  a  table  of  information  that  lists  maintenance 
requirements  by  maintenance  job,  maintenance  action, 
component,  maintenance  organization,  and  maintenance  type. 
The  analyst  will  be  able  to  sort  and  display  the  information 
in  the  report  for  any  of  the  above  categories.  For  example, 
the  analyst  can  choose  to  display  all  of  the  maintenance 
requirements  for  each  maintenance  job  or  to  display  the 
maintenance  requirements  by  component  or  functional  system. 

The  second  type  of  report  that  is  produced 
automatically  is  the  Maintenance  Headcount  Requirements. 

This  report  is  actually  a  set  of  histograms  that  identify 
the  actual  numbers  of  people  required  for  each  maintenance 
job  and  the  percentage  of  time  that  number  of  people  were 
needed  to  maintain  the  system.  The  analyst  will  need  both 
the  Maintenance  Manhour  Requirements  summary  report  and  the 
Maintenance  Headcount  Requirements  histograms  to  accurately 
evaluate  the  maintenance  requirements  for  the  proposed 
system  design. 

The  Analyze  Simulation  Results  portion  of  the  MMAA 
software  will  also  give  the  analyst  an  estimate  of  system 
availability  and  reliability  based  on  missions  missed, 
missions  completed,  and  missions  aborted  during  the 
simulation.  The  section  4  description  of  the  algorithms 
used  to  develop  the  Maintenance  Requirements  Simulation 
Model  contains  a  description  of  the  algorithmes  used  to 
calculate  availability  and  reliability. 

The  analyst  will  compare  the  output  that  is  obtained 
from  each  execution  of  the  model  to  the  data  contained  in 
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the  Maintenance  Manpower  Constraints  Report  and  the  Source 
MOS  Report  obtained  from  the  Product  2  MCEA  analysis  and  the 
performance  requirements  obtained  from  the  System  RAM 
Criteria  file  and  the  Corrective  Maintenance  Criteria  file 
that  were  derived  during  the  Product  1  SPREA  analysis. 

The  flow  diagram  of  the  process  of  performing  Step  7 
are  included  on  the  following  page. 
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3 . 5 . 7 . 3  Output 


The  output  of  this  step  is  the  identification  of 
potential  design  deficiencies  in  terms  of  1)  the  estimated 
manpower  required  to  maintain  the  system  as  compared  to  the 
manpower  constraints  and  2)  the  estimated  availability  and 
reliability  of  the  system  as  related  to  maintenance 
requirements  compared  to  the  system  performance  requirements 
determined  in  the  Product  1  SPREA  analysis. 

Another  output  of  this  step  is  a  set  of  maintenance 
reports  of  manhour  and  headcount  requirments  reports  that 
can  be  used  in  the  Trade-off  Analysis  process  that  will  be 
aided  by  product  6  of  the  (MPT)^  effort. 


3. 5. 7. 4  User  Interface 

The  user  interfaces  that  apply  to  this  step . are 
described  in  detail  on  the  following  pages.  Please  note 
that  all  screens  for  the  MMAA  are  labeled  "Screen  l.X". 
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Screen  1.89 


Analyze  Simulation  Results  menu. 


From  this  screen,  the  user  can  use  normal  menu 
selection  procedures  to  review  the  stored  results  of 
the  most  recent  Maintenance  Requirements  Simulation 
Model  execution. 

User  Actions; 

1.  Review  Manhour  Requirements  -  Next  screen  is  1.90. 

2.  Review  Headcount  Requirements  -  Next  screen  is 
1.92. 

3.  Review  System  Availability  Estimates  -  Next  screen 
is  1.106. 


4.  Review  System  Reliability  Estimates  -  Next  screen 
is  1.107. 

5.  Review  Simulation  Errors  file  -  Next  screen  is 
1.108. 


<ESC>  Returns  the  user  to  screen  1.1. 
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PATH:  MDA> MMAA> Analyze  Simulation  Results 


MODE:  Work 


ANALYZE  SIMULATION  RESULTS 


1.  Review  Manhour  Requirements 
£.  Review  Headcount  Requirements 

3.  Review  System  Availability 

4.  Review  System  Reliability 

5.  Review  Simulation  Errors 


Screen  1.89  -  Analyze  Simulation  Results  menu. 
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Screen  1.90  -  Maintenance  Manhour  Requirements  report. 

This  report  shows: 

o  maintenance  jobs 

o  maintenance  actions  per  job 

o  the  component  for  each  maintenance  action 
o  the  number  of  times  the  maintenance  action 
was  performed 

o  the  organization  that  performed  the 

maintenance 

o  the  type  of  maintenance 

o  the  total  manhours  spent  performing  the 
maintenance 

The  Maintenance  Manhour  Requirements  report  can  be 
sorted  by  any  of  the  categories  listed  above  and  re¬ 
displayed  in  the  new  format.  It  can  also  be  printed  in 
various  formats. 

From  this  screen,  the  user  can  use  arrow  keys  to  scroll 
through  pages  of  the  report  or  access  the  menu  bar 
commands  to  sort  or  print  the  report  or  to  switch  to 
view  the  maintenance  headcount  requirements. 

User  Actions: 

Using  the  arrow  keys,  the  user  can  scroll  through  the 
report . 

F9  -  Displays  the  menu  bar  commands.  Next  screen  is 
1.91. 

<ESC>  -  Returns  the  user  to  screen  1.89. 
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PATH;  MDA> MMAA> Analyse  Simulation  Results 


MODE:  Work 


MAINTENANCE  MANHOUR  REQUIREMENTS 

Job 

Maintenance 

Component 

# 

Org 

Type 

Total 

(MOS/Skill) 

Action 

Name 

Manhours 

63D10 

replace 

Cylinder  head 

3 

ds 

C 

81.2 

repair 

Fuel  I n.j ect  i on 

7 

gs 

c 

28.0 

repair 

Master 

Cy 1 inder 

1 

c 

12.  2 

inspect 

Fuel  Injection 

12 

9.  5 

inspect 

Crankshaft 

38 

gs 

p 

17.  0 

remove/ 

replace 

Seals,  main 

1 

gs 

c 

12.  5 

subtotals 

*  62 

*  100.4 

63DE0 

repair 

Rod , 

2 

ds 

c 

10.5 

connecting 

remove/ 

replace 

Crankshaft 

1 

ds 

c 

13.  0 

repair 

Engine  mount 

3 

ds 

c 

9.  5 

inspect 

Engine  mount 

27 

gs 

p 

13.  5 

Screen  1.90  -  Maintenance  Manhour  Requirements  report. 
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Screen  1.91  -  Maintenance  Manhour  Requirements  report  with 
menu  bar  commands  displayed. 

From  this  screen,  the  user  can  switch  to  the 
Maintenance  Headcount  Requirements  report,  sort  and 
display  the  maintenance  requirements  data  by 
categories,  or  print  the  Maintenance  Manhour 
Requirements  report. 

User  Actions; 

Headcount  When  this  command  is  selected,  the  user  can 

review  the  Maintenance  Headcount  Requirements 
reports.  Next  screen  is  1.92. 

sort  When  this  command  is  selected  the  user  can 

sort  the  Maintenance  Manhour  Requirements 
data  by  one  of  the  defined  categories.  Next 
screen  is  1.99. 

print  When  this  commanc  is  selected,  the  user  can 
print  all  or  portions  of  the  Maintenance 
Manhour  Requirements  report.  Next  screen  is 
1.103. 

<ESC>  Returns  the  user  to  screen  1.90. 
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PftTH:  MDA> MM Aft> Analyze  Simulation  Results  MODE:  Work 

Headcount  Sort  Print 

Display  a  headcount  requirements  histogram  for  current /selected  MOS/Skill  levels 


MAINTENANCE  MANHOUR  REQUIREMENTS 

Job 

Maint enance 

Component 

# 

Org 

Type 

Total 

<MOS/Skill) 

Act  ion 

Name 

Manhours 

63D10 

replace 

Cylinder  head 

3 

ds 

C 

ai.£ 

repair 

Fuel  Injection 

7 

gs 

C 

as.  0 

repair 

Master 

Cy 1 inder 

1 

gs 

c 

12.  a 

inspect 

Fuel  Injection 

la 

9.  5 

inspect 

Crankshaft 

38 

gs 

p 

17.  0 

remove/ 

replace 

Seals,  main 

1 

gs 

C 

la.  5 

subtotals 

*  62 

*  100.4 

63DaO 

repair 

Rod , 

a 

ds 

c 

10.  5 

connect ing 

remove/ 

replace 

Crankshaft 

1 

ds 

c 

13.0 

repair 

Engine  mount 

ds 

c 

9.  5 

inspect 

Engine  mount 

£7 

gs 

p 

13.5 

Screen  1.91  -  Maintenance  Manhour  Requirements  report  with  menu 
bar  commands  displayed. 
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Screen  1.92  -  Maintenance  Headcount  Requirements  histogram. 

The  histogram  that  displays  is  for  the  same  MOS/Skill 
Level  that  is  currently  highlighted  in  the  Maintenance 
Manhour  Requirements  Report.  The  user  can  page  through 
the  histograms  for  all  of  the  maintenance  jobs  by 
repeatedly  pressing  the  <ENTER>  key.  The  user  can 
choose  to  print  the  headcount  histogram(s)  or  switch 
back  to  the  Maintenance  Manhour  Requirements  report  by 
accessing  the  menu  bar  commands. 

User  Actions; 

<ENTER>  Displays  a  headcount  histogram  for  the  next 
maintenance  job. 

F9  Displays  the  menu  bar  commands  for  this 

screen.  Next  screen  is  1.93. 

<ESC>  Returns  the  user  to  screen  1.89. 
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PftTH:  MDfl>  MM  Aft  >  Pinal  yze  Simulation  Results 


MODE:  Work 


MAINTENANCE  HEADCOUNT  REQUIREMENTS 


Headcount  Required 


Screen  1.92  -  Maintenance  Headcount  Requirements  histogram. 
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Screen  1.93  -  Maintenance  Headcount  Requirements  histogram 
with  menu  bar  commands  displayed. 

From  this  screen,  the  user  can  choose  to  print  either 
the  currently  displayed  headcount  histogram,  the 
headcount  histograms  for  all  of  the  maintenance  jobs 
required  for  the  current  system  or  to  display  the 
Maintenance  Manhour  Requirements  report. 

User  Actions; 

Manhours  Displays  the  Maintenance  Manhour  Requirements 
report.  Next  screen  is  1.90. 

Print  Displays  the  print  menu.  Next  screen  is 
1.95. 

<ESC>  Returns  the  user  to  screen  1.92. 
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MODE:  Work 


PATH:  MDA> MMAA> Analyze  Simulation  Results 
Manhours  Print 

Display  a  table  of  maintenance  manhour  requirements 

MAINTENANCE  HEADCOUNT  REQUIREMENTS 
MOS/Skill :  63D20 


100 

80 

frequency 

i%)  60 

40 

20 

O 


1  2  3  4  5  6  7  8 

Headcount  Req  u i red 


Screen  1.93  -  Maintenance  Headcount  Requirements  histogram  with 
menu  bar  commands  displayed. 
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Screen  1.95  -  Print  Headcount  Histogram (s)  menu. 

From  this  screen,  the  user  can  choose  to  print  the 
currently  displayed  histogram  or  all  headcount 
histograms . 

User  Actions; 

1.  For  this  job  only  -  Prints  only  the  currently 
displayed  histogram.  Next  screen  is  1.97. 

2.  For  all  maintenance  jobs  -  Will  print  a  headcount 
histogram  for  all  maintenance  jobs  for  the  current 
system.  Next  screen  is  1.96. 


<ESC>  Returns  the  user  to  screen  1.93. 


MODE:  Work 


PftTH:  MDA>MMAfl> Analyze  Simulation  Results 
Manhours  Print 

Print  maintenance  headcount  requirements  histogram 

MAINTENANCE  HEADCOUNT  REQUIREMENTS 
MOS/Skill:  63D£0 

100 
80  I 

frequency  _ 

<%)  60 

40 

£0  I 

O  _ _ 

1  a  3  4  5  6  .7  8 

Headcount  Req u i red 


PRINT  HEADCOUNT  HISTOGRAM <S) 


1«  For  this  job  only 
£.  For  all  maintenance  jobs 


Screen  1.95  -  Print  Headcount  Histogram(s)  menu. 
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Screen  1.96  -  Maintenance  Headcount  Requirements  print 
message. 

This  is  an  informational  message  informing  the  user  of 
how  many  histograms  there  are  to  print  and  the 
estimated  completion  time. 

User  Actions; 

None.  Next  screen  is  1.97. 


<ESC>  Aborts  the  printing  job.  Next  screen  is  1.96A??. 


MODE;  Wait 


PftTH;  MDA> MMAA> Analyze  Simulation  Results 
Manhours  Print 

Print  maintenance  headcount  requirements  histogram 

MAINTENANCE  HEADCOUNT  REQUIREMENTS 


100 
80 

frequency 

i%)  60 

40 

£0 

0 

1  £  3  4  5  6  7  8 

Headcount  Req u i red 


Currently  printing  all  headcount 
histograms. 

There  are  5£  maintenance  .jobs  for 
this  system,  estimated  completion 
t i me :  1 £ ; 1 5 


Press  <ESC>  to  Abort 


Screen  1.96  - 


Maintenance  Headcount  Rec]uirenients  print 


message. 
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Screen  1.96A  -  Print  Job  Aborted  message. 

Informs  the  user  that  the  printing  of  all  Maintenance 
Headcount  Requirements  histograms  was  aborted. 

User  Actions; 

<ENTER>  Returns  the  user  to  screen  1.93. 
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PATH:  MDA> MMAA> Analyze  Simulation  Results 


MODE:  Work 


frequency 

{%) 


MAINTENANCE  HEADCOUNT  REQUIREMENTS 


100 

80 

60 

40 


PRINTING  ABORTED 
Press  <ENTER>  to  continue 


£0 


O 


1£  3  4  5  6  7  8 

Headcount  Required 


Screen  1,96A  -  Print  Job  Aborted  message. 
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Screen  1.99  -  Sort  Maintenance  Manhour  Data  menu. 

From  this  screen,  the  user  can  choose  a  category  by 

which  to  sort  maintenance  manhour  data. 

User  Actions; 

1.  Maintenance  Job  -  Sorts  and  displays  maintenance 
manhour  requirements  by  maintenance  job.  Next 
screen  is  1.100. 

2.  Functional  System  -  Sorts  and  displays  maintenance 
manhour  requirements  by  Functional  System.  Next 
screen  is  1.100. 

3 .  Maintenance  Organization  -  Sorts  and  displays 
maintenance  manhour  requirements  by  maintenance 
organization.  Next  screen  is  l.lOO. 

4.  Maintenance  Type  -  Sorts  and  displays  maintenance 
manhour  requirements  by  maintenance  type.  Next 
screen  is  1.100. 

<ESC>  Returns  the  user  to  screen  1.91. 
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MODE:  Work 


PftTH:  MDA> MMftft) final yze  Simulation  Results 
Headcount  Sort  Print 

Display  maintenance  manhour  requirements  by  selected  categories 


MfilNTENfiNCE  MfiNHOUR  REQUIREMENTS 


Job 

(MOS/Skill) 


63D10 


Main 

fic 


T 


T 


repl 
re  pa 
repa 

insp 

insp 


SORT  MfilNTENfiNCE  MfiNHOUR  DfiTfi  BYi 


1.  Maintenance  Job  <MOS/Skill) 
S.  Functional  System 

3.  Maintenance  Organization 

4.  Maintenance  Type 


remove/ 

replace 

Seals,  main 

1 

subtotals 

*  62 

63D£0 

repair 

Rod, 

2 

connect ing 

remove/ 

replace 

Crankshaft 

1 

repair 

Engine  mount 

3 

inspect 

Engine  mount 

27 

gs 


ds 


ds 

ds 

gs 


Type 


C 

C 

C 

P 

C 


c 

c 

p 


Total 

Manhours 


ai. 

28. 

12. 

9. 

17. 

12. 

*  100. 
10. 


13. 

9. 

13. 


Screen  1.99  -  Sort  Maintenance  Manhour  Data  menu. 
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c.n  ui  o  ui  ^  m  o  cn  ro  o  ro 


Screen  1.100  -  Maintenance  Manhour  Requirements  with  "SORT 
OPERATION  IN  PROGRESS"  message  displayed. 

User  Actions; 

None.  The  next  screen  l.lOl  is  an  example  of  a 
Maintenance  Manhour  Requirements  report  sorted  by 
Maintenance  Organization. 
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MODE:  Wait 


PftTH;  MDfi> MMflft) Analyze  Simulation  Results 
Headcount  Sort  Print 

Display  maintenance  manhour  requirements  by  selected  categories 


MAINTENANCE  MANHOUR  REQUIREMENTS 


Job 

(MOS/Skill) 

Maint enance 
fict ion 

Component 

Name 

# 

□rg 

Type 

Total 

Manhours 

63D10 

replace 

r 

n 

c 

21.2 

repair 

c 

28.  0 

repair 

SORT  OPERATION 

IN  PROGRESS 

c 

12.2 

inspect 

9.  5 

inspect 

Crankshaft 

38 

gs 

P 

17.  0 

remove/ 

replace 

Seals,  main 

1 

gs 

c 

12,5 

subtotals 

»  62 

*  100.4 

63D20 

repair 

Rod , 

2 

ds 

c 

10.5 

connecting 

remove/ 

replace 

Crankshaft 

1 

ds 

c 

13.0 

repair 

Engine  mount 

ds 

c 

9.  5 

inspect 

Engine  mount 

27 

gs 

p 

13.  5 

Screen  1.100  -  Maintenance  Manhour  Requirements  with  "SORT 


Screen  1.101  -  Maintenance  Manhour  Requirements  report 
sorted  and  displayed  by  Maintenance 
Organization. 

User  Actions; 

The  user  actions  from  this  screen  are  the  same  as  those 
for  step  1.90. 
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PATH:  MDA> MMAA> Analyse  Simulation  Results 


MODE:  Work 


MAINTENANCE  MANHOUR  REQUIREMENTS 

Ong 

Job 

Maintenance 

Component 

# 

Type 

Total 

<MOS/Skill) 

fiction 

Name 

Manhours 

ds 

63D10 

replace 

Cylinder  head 

3 

C 

£1.£ 

63D20 

repair 

Rod  y 

£ 

c 

£8.  0 

connect ing 

remove/ 

C 

1£.£ 

replace 

Crankshaft 

1 

13.0 

repair 

Engine  mount 

3 

C 

9.  5 

inspect 

Engine  mount 

£7 

P 

13.5 

replace 

Seals,  main 

1 

c 

1£.  5 

subtotals 

*  37 

*  109.9 

as 

&3D20 

repair 

Master 

Cy 1 inder 

1 

c 

1£.  £ 

inspect 

F ue  1  I  n.j  ect  i  on 

1£ 

p 

9.  5 

inspect 

Crankshaft 

38 

p 

17.0 

Screen  1.101  -  Maintenance  Manhour  Requirements  report  sorted  and 
dispiayed  by  Maintenance  Organization. 


Screen  1.103  -  Print  Maintenance  Manhour  Requirements  menu. 

From  this  screen,  the  user  can  choose  to  print  only  the 
information  that  is  currently  displayed  on  the  screen, 
all  of  the  information  for  the  category  highlighted  in 
the  left  most  column,  or  all  of  the  information  for  the 
entire  system. 

User  Actions: 

1.  This  page  only  -  Prints  only  the  information 
displayed  on  the  screen.  Next  screen  is  1.104. 

2.  All  requirements  for  the  highlighted  job  -  Prints 
all  information  for  the  category  highlighted  in 
the  left  column  even  if  it  extends  beyond  the 
current  screen.  Next  screen  is  1.104. 

3 .  All  requirements  for  the  entire  system  -  Prints 
all  of  the  Maintenance  Manhour  Requirements.  Next 
screen  is  1.104. 

<ESC>  Returns  the  user  to  screen  1.91. 
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MODE :  Work 


PATH:  MDA>MMAA> Analyze  Simulation  Results 
Headcount  Sort  Print 

Print  all  or  selected  portions  of  the  Maintenance  Manhour  Requirements  table 


Job 

Ma 

(MOS/Skill) 

63D 10 

re 

re 

re 

.?  ”  -jt  ot  a  1  s 
G3DE0 


PRINT  MAINTENANCE  MANHOUR  REQUIREMENTS 


.  This  page  only 

S.  All  requirements  for  the  highlighted  job 
3.  All  requirements  for  the  entire  system 


Total 

Manhours 


ai.s 
28.  0 


inspect 

Fuel  Injection  1£ 

9.  5 

inspect 

Crankshaft  38 

gs 

p 

17.  0 

remove/ 

replace 

Seals,  main  1 

gs 

c 

12.  5 

*  82 

*  100.4 

repair 

Rod,  2 

ds 

c 

10.  5 

connect ing 

remove/ 

replace 

Crankshaft  1 

ds 

c 

13.0 

repair 

Engine  mount  3 

ds 

c 

9.5 

inspect 

Engine  mount  27 

gs 

p 

13.  5 

Screen  1.103  -  Print  Maintenance  Manhour  Requirements  menu. 
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Screen  1.104  -  Maintenance  Manhour  Requirements  menu  with 
the  "PRINTING”  message  displayed. 

User  Actions; 

None.  Next  Screen  is  1.105. 

<ESC>  Aborts  the  print  request.  Returns  the  user 
to  screen  1.91. 
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MODE;  Wait 


PATH;  MDA> MMfifl) Analyze  Simulation  Results 
Headcount  Sort  Print 

Print  all  or  selected  portions  of  the  Maintenance  Manhour  Requirements  table 


MAINTENANCE  MANHOUR  F 

REQUIREMENTS 

Job 

(MOS/Skill) 

Maintenance 

Action 

Component 

Name 

# 

Org 

Type 

Total 

Manhours 

Screen  1.104  -  Maintenance  Manhour  Requirements  menu  with  the 
"PRINTING"  message  displayed. 
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Screen  1.105  -  Maintenance  Manhour  Requirements  menu  with 
"PRINTING  COMPLETE"  message  displayed. 

User  Actions! 

<ENTER>  Next  screen  is  1.91. 
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PftTH:  MDA> MMftft) final yze  Simulation  Results  MODE;  Work 

Headcount  Sort  Print 

Print  all  or  selected  portions  of  the  Maintenance  Manhour  Requirements  table 


Job 

(MOS/Skill) 


&3D10 


subtotals 
63D20  1 


MfilNTENfiNCE  MfiNHOUR  REQUIREMENTS 


Maintenance 

fiction 


replace 

repair 

repair 


inspect 

inspect 


Component 

Name 


# 

Org 

Type 


PRINTING  COMPLETE 


F  Press  <ENTER>  to  continue 

cl - - 


Total 

Manhours 


Screen  1.105  -  Maintenance  Manhour  Requirements  menu  with 
"PRINTING  COMPLETE"  message  displayed. 


I 


21.2 

28.0 


12.  2 
9.  5 
17.  0 


remove/ 

replace 

Seals,  main 

1 

gs 

C 

12.5 

* 

*  100.4 

repair 

Rod, 

connecting 

£ 

ds 

C 

10.  5 

remove/ 

replace 

Crankshaft 

1 

ds 

C 

13.0 

repair 

Engine  mount 

3 

ds 

C 

9.  5 

inspect 

Engine  mount 

£7 

gs 

P 

13.  5 
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Screen  1.106  -  System  Availability  Estimates  report 


User  Actions; 

P  Prints  the  report.  Next  screen  is  1.89. 

<ENTER>  Returns  the  user  to  screen  1.89. 

<ESC>  Returns  the  user  to  screen  1.89. 


PATH:  MDft>  MMPift)  Analyze  Simulation  Results 


MODE:  Wov'k 


SYSTEM  AVAILABILITY  REPORT 

Mission:  Transport  Combat  Troops 

Maintenance  Scenario  file:  TRANSOl 
System  Name:  UH-*60  Black  Hawk 

Mean  Time  Between  Component  Failures: 

708.  a 

Mean  Time  to  Repair: 

11.5 

Inherent  Availability: 

98,  4-/- 

Press  <P>  to  print  Press  < ENTER)  to 

cont inue 

Screen  1.106  -  System  Availability  Estimates  report. 
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Screen  1.107  -  System  Reliability  Estimates  report 


User  Actions; 

P  Prints  the  report.  Next  screen  is  1.89. 

<ENTER>  Returns  the  user  to  screen  1.89. 

<ESC>  Returns  the  user  to  screen  1.89. 
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PATH:  MDfl>  MMAft)  Analyze  Simulation  FReeults  MODE:  Work 


SYSTEM  RELIABILITY  REPORT 

Mission;  Transport  Combat  Troops 

Maintenance  Scenario  file;  TRANSOl 

System  Name;  UH-60  Black  Hawk 

MISSION  RELIABILITY 

EQUIPMENT  SROUP  RELIABILITY/MISSION 

M i ss i ons  St  art  ed ;  1515 

Armament :  94% 

Missions  Completed;  1457 

Mobility  Gv‘'oap;  89% 

Missions  Aborted:  58 

Comrnun i cat  i ons  Group :  96% 

Reliability;  96^ 

i 

Total  System:  80.3% 

Press  <P>  to  print 

Press  <ENTER>  to  continue 

Screen  1.107  -  System  Reliability  Estimates  report. 
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Screen  1.108  -  Simulation  Errors  report. 

User  Actions; 

P  Prints  the  report.  Next  screen  is  1.89. 

<ENTER>  Returns  the  user  to  screen  1.89. 

<ESC>  Returns  the  user  to  screen  1.89. 
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PATH:  MDft) MMAA) Analyze  Simulation  Results 


MODE:  Work 


SIMULATION  ERRORS  FILE 


System  Name:  UH-60  Black  Hawk 

Maintenance  Scenario  file:  TRANSOl  Errors  Encountered:  1 


Functional  System:  Engine 

Message:  Missing  (MOUBF)  for  (repair)  (connecting  rod) 


Screen  1.108  -  Simulation  Errors  report. 
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3.5.8  STEP  8  “  Investigate  potential  solutions  to  maintenance 
deficiencies  by  modifying  Component  Maintenance 
Parameters  and  re-running  the  Maintenance 
Requirements  Simulation  Model. 

3 . 5 . 8 . 1  Input 

External ;  The  contractor's  design  engineers,  subject  matter 
experts,  analyst  judgement. 

Internal ;  Maintenance  workload  deficiencies  in  the  system 
that  were  identified  in  Step  7. 

3 . 5 . 8 . 2  Process 

When  the  results  of  the  Maintenance  Requirements 
Simulation  Model  indicate  that  the  manpower  required  to 
maintain  the  system  under  evaluation  exceeds  the  manpower 
constraints  that  were  identified  in  the  Product  2  MCEA 
analysis  or  that  the  system  availability/reliability 
estimates  are  deficient  when  compared  to  the  requirements 
obtained  from  the  Product  1  SPREA  analysis,  the  analyst  can 
use  the  MMAA  to  investigate  potential  solutions  to  the 
design  deficiencies.  The  analyst  can  use  the  MMAA  as  a  tool 
to  estimate  the  effects  of  changes  in  the  Component 
Maintenance  Parameters  on  maintenance  workload  by  modifying 
one  or  more  parameters  and  re-executing  the  simulation 
model.  For  example,  if  the  contractor  can  increase  the  mean 
time  between  failure  for  a  particular  component  or 
functional  system  by  10%,  what  impact  would  such  a  change 
have  on  the  system  availability  or  reliability?  This 
information  could  be  presented  to  the  contractor  for 
potential  resolution  of  the  deficiency. 
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3 . 5 . 8 . 3  Outputs 


The  outputs  of  this  Step  are  simulatioSi  results  files 
that  represent  potential  solutions  to  maintenance 
requirements  deficiencies.  These  results  files  will  also  be 
available  as  input  to  the  analysis  aided  by  Product  6. 


3 . 5 . 8 . 4  User  Interface 

Since  the  execution  of  this  step  only  involves  re¬ 
application  of  the  MMAA  with  potentially  different  input 
data  to  investigate  potential  changes  in  maintenance 
requirements,  no  additional  software  is  reqtiired. 
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